ست ثغرات في Git: حدّثوا أكثر من سطر الأوامر

إذا حدّثتم Git في الطرفية، فالمهمة لم تنتهِ بعد: قد تشغّل بعض التطبيقات وبيئات البناء نسخًا مستقلة منه. ففي 10 نوفمبر 2026، أصدر مشروع Git إصلاحات لست ثغرات، تراوحت بين تنفيذ التعليمات البرمجية أثناء الاستنساخ المتكرر وتلف الذاكرة أثناء الدمج. لذلك ينبغي التحقق من كل بيئة تعالج المستودعات أو محتوياتها، لا الاكتفاء بنتيجة الأمر git --version في الصدفة.

ما الذي تغيّر في التحديث

أُدرجت الإصلاحات في Git 2.56.1، ونُقلت إلى الفروع المدعومة: 2.55.1 و2.54.1 و2.53.1 و2.52.1 و2.51.3 و2.50.2. يعالج التحديث ست مشكلات في أجزاء مختلفة من Git، تتعلق بالمسارات والروابط والتوقيعات والتصحيحات الثنائية وعمليات الدمج وتدفّقات الاستيراد. وقد نشرت GitHub في 10 نوفمبر شرح الثغرات وتوصية التحديث، فيما تسرد ملاحظات إصدار Git 2.56.1 معرّفات CVE التي عالجتها هذه السلسلة.

عمليًا، ينبغي تحديث Git في ثلاثة مواضع: أجهزة العمل، وأنظمة الأتمتة، والتطبيقات التي تتضمن إصدارًا خاصًا بها من Git. ومن السهل إغفال النقطة الأخيرة: فتحديث حزمة النظام لا يحدّث تلقائيًا الإصدار الموجود في كل عميل أو صورة بناء.

لماذا يستحق الاستنساخ المتكرر الاهتمام

يبدأ أوضح سيناريو باستنساخ متكرر لمستودع غير موثوق به. فقد يسمح اقتطاع طول المسار بمرور مسار طويل جدًا خلال الفحص باسم معيّن، ثم يُكتب على القرص بعد تقصيره. وفي السيناريو الذي وصفه Git، أتاح ذلك استبدال ملف .git الخاص بوحدة فرعية برابط رمزي إلى مجلد يحتوي على إعدادات أو خطافات خبيثة. وعند تفاعل Git مع هذا المحتوى لاحقًا، كان من الممكن تنفيذ تعليمات برمجية يحددها المهاجم.

من المهم عمليًا أن هذا السيناريو يتطلب مستودعًا مُعدًّا خصيصًا وعملية مناسبة. وينبغي للفرق التي تستنسخ بانتظام مشاريع من مصادر خارجية باستخدام الخيار --recurse-submodules إعطاء الأولوية لتحديث بيئات العملاء والأتمتة. يرفض الإصلاح المسارات المفرطة الطول قبل اقتطاعها.

مواضع أخرى يعالج فيها Git بيانات غير موثوق بها

تظهر مشكلة أخرى عند استنساخ مستودع فارغ عبر Git protocol v2. إذ كان بإمكان الخادم إرسال رابط HEAD باسم فرع يتضمن مكونات لتجاوز المجلدات؛ وقد تكتب عملية تحديث الفرع لاحقًا ملفًا خارج مجلد الروابط المتوقع. وفي إصدارات Git المصححة، يجري التحقق من هذا الهدف ومن أسماء الروابط الأخرى الواردة عبر البروتوكول.

كما أثرت ثغرات منفصلة في عمليات الدمج والتصحيحات. فعند معالجة التوقيعات، كانت هناك مصفوفة ثابتة لا تتسع إلا لتوقيعين؛ وكان من الممكن أن تتسبب رسالة مُعدّة عمدًا وتحتوي على عدد أكبر من التوقيعات في الكتابة خارج حدود المصفوفة وإفساد الذاكرة. وعند تطبيق تصحيح ثنائي، كان فحص الحجم يعتمد على التمثيل الأصلي، رغم أن البيانات المضغوطة قد تتمدد إلى حجم أكبر بكثير. أما الآن، فيتحقق Git من الحجم المعلن بعد فك الضغط قبل المعالجة.

كذلك قد تؤدي عمليات الدمج الكبيرة إلى تجاوز السعة عند حساب حجم المخزن المؤقت المطلوب، ثم إلى الكتابة خارج حدوده. ويشمل ذلك خدمات الاستضافة والتطبيقات التي تدمج محتوى غير موثوق به. وأخيرًا، فُرضت قيود على ثلاثة خيارات في git fast-import عند معالجة أوامر من تدفق الإدخال: إذ كان بإمكان rewrite-submodules-from وrewrite-submodules-to قراءة ملفات عشوائية، بينما كان بإمكان export-pack-edges إنشاء ملفات أو إضافة بيانات إلى ملفات موجودة. أصبحت هذه الخيارات محظورة ما لم يُحدَّد صراحةً الخيار --allow-unsafe-features؛ ولا ينبغي استخدامه إلا مع مولّد تدفق موثوق به.

أين تبحثون عن نسخ Git المستقلة

يمكن للمطور أن يبدأ بحصر مصادر تشغيل Git. تحقّقوا من الإصدار في الطرفية، واستخدموا أداة التحقق من التحديثات المدمجة في بيئات التطوير المتكاملة وعملاء Git على سطح المكتب. ثم راجعوا صور CI والحاويات ومشغّلات المهام والوظائف الخادمية التي تنفّذ الاستنساخ أو الدمج أو تطبّق تصحيحات ثنائية أو تشغّل fast-import. فوجود إصدار حديث من Git على المضيف لا يضمن أن التطبيق يستخدمه.

ومن المفيد في المؤسسات مراجعة الصور الأصلية وبيئات العمل المنشورة بالفعل: فقد يحتفظ مشغّل دائم أو خدمة داخلية بملف تنفيذي قديم بعد تحديث الصورة الأساسية. وتشير GitHub إلى أن الإصدارات المصححة لـ GitHub Enterprise Server هي 3.19.15 و3.20.11 و3.21.9 و3.22.4. كما أفادت الشركة بأنها نشرت الإصلاحات بالفعل على github.com وGitHub Enterprise Cloud، بما في ذلك الخيارات التي تستضيف البيانات. أما إصدارات GitHub Desktop وتطبيق GitHub Copilot المزودة بإصلاح Git، فما زالت قيد التنسيق؛ وكذلك لم تصدر بعد الإصدارات المصححة لـ Codespaces وGitHub Actions.

كيفية الحد من الخطر قبل التحديث

إذا تعذّر تثبيت الإصلاح فورًا، فقيّدوا مؤقتًا العمليات التي تتعامل مع بيانات غير موثوق بها: استنسخوا المستودعات من خوادم موثوقة فقط، وتجنبوا الاستنساخ المتكرر للمشاريع غير المفحوصة، ولا تدمجوا محتواها أو تطبقوا التصحيحات الثنائية أو تدفّقات fast-import الواردة منها. تقلل هذه الإجراءات التعرض لسيناريوهات محددة تتأثر بالثغرات، لكنها لا تغني عن التحديث.

الخلاصة العملية بسيطة: ابحثوا عن إصلاح Git في الموضع الذي يشغّل فيه البرنامج Git فعليًا. أمر الطرفية موضع واحد فقط؛ أما عملاء التطوير وأنظمة CI والخدمات التي تعالج المستودعات فتحتاج إلى تحقق مستقل.