ثغرة Gogs RCE حرجة: تنفيذ تعليمات برمجية عن بُعد لأي مستخدم موثق

مقدمة تحليلية

كشفت Rapid7 مؤخرًا عن ثغرة أمنية بالغة الخطورة في Gogs، خدمة Git مفتوحة المصدر المستضافة ذاتيًا، والتي تحمل تصنيف CVSS يبلغ 9.4. تسمح هذه الثغرة لأي مستخدم موثق بتنفيذ تعليمات برمجية عن بُعد (RCE) على الخادم تحت ظروف معينة، دون الحاجة إلى امتيازات إدارية أو حتى تفاعل من مستخدمين آخرين. الأشد خطورة هو أن هذه الثغرة، التي تم الإبلاغ عنها للمطورين في 17 مارس 2026، لا تزال بلا تصحيح حتى تاريخ النشر، مما يترك الآلاف من الخوادم المعرضة للهجوم. تتجاوز تداعيات هذه الثغرة مجرد التحكم في التعليمات البرمجية؛ فهي تفتح الباب أمام هجمات واسعة النطاق تشمل اختراق الخادم بالكامل، الوصول إلى جميع المستودعات الموجودة على المنصة، سرقة بيانات الاعتماد، والتحرك الجانبي داخل الشبكة لاستهداف أنظمة أخرى. كما يمكن أن تؤدي إلى خرق بيانات متعدد المستأجرين، حيث يمكن للمهاجم قراءة المستودعات الخاصة للمستخدمين الآخرين المستضافة على نفس الخادم المشترك، مما يشكل تهديدًا وجوديًا للبيانات الحساسة والملكية الفكرية.

التحليل التقني

تكمن الثغرة في طريقة تعامل Gogs مع عمليات دمج 'Rebase before merging' (إعادة الأساس قبل الدمج) في Git. يستغل المهاجم القدرة على إنشاء طلب سحب (pull request) باستخدام اسم فرع خبيث. هذا الاسم الخبيث يقوم بحقن علامة `--exec` في أمر `git rebase`، وهو أمر يسمح بتنفيذ أمر shell بعد كل commit يتم إعادة تشغيله.

• آلية الهجوم: يقوم المهاجم بإنشاء مستودع خاص به على أي نسخة Gogs بالتهيئة الافتراضية. بصفته مالك المستودع، يمكنه تفعيل خيار دمج Rebase (وهو تبديل واحد بسيط في الإعدادات). بعد ذلك، يقوم بإنشاء فرع جديد يحمل اسمًا مصممًا لحقن أمر معين عبر علامة `--exec` في `git rebase`. عند محاولة دمج هذا الفرع، يتم تنفيذ الأمر الخبيث على الخادم.
• الامتيازات المطلوبة: تتطلب الثغرة مستخدمًا موثقًا فقط. في حال كانت إعدادات Gogs تسمح بتسجيل المستخدمين وإنشاء المستودعات بشكل افتراضي، يمكن لأي ممثل تهديد غير موثق إنشاء حساب واستغلال الثغرة. أما في الحالات التي تكون فيها قيود على إنشاء المستودعات، يحتاج المهاجم إلى صلاحية كتابة (write access) لأي مستودع مُفعل فيه خيار Rebase.
• التأثير: تنفيذ تعليمات برمجية عن بُعد على الخادم، مما يمنح المهاجم سيطرة كاملة.
• المنصات المتأثرة: جميع الأنظمة الأساسية المدعومة، بما في ذلك Windows وLinux وmacOS.
• نقص CVE: لا يوجد معرف CVE محدد لهذه الثغرة حتى الآن، مما قد يعيق تتبعها وتصنيفها بشكل موحد.
• أداة الاستغلال: قامت Rapid7 بإطلاق وحدة Metasploit (Metasploit module) التي تقوم بأتمتة سلسلة الاستغلال الكاملة ضد أهداف Linux وWindows. تدعم الوحدة وضعين: وضع افتراضي يقوم بإنشاء مستودع مؤقت تحت حساب المهاجم، ويشغل الاستغلال، ثم يحذف المستودع؛ ووضع آخر يستهدف مستودعًا يمتلك فيه المهاجم بالفعل صلاحيات الكتابة والدمج.

السياق وتأثير السوق

تُعد Gogs خيارًا شائعًا للمؤسسات والأفراد الذين يفضلون استضافة خدمة Git الخاصة بهم، لما توفره من سهولة في الإعداد والصيانة. هذا الانتشار يجعل الثغرة شديدة الخطورة، حيث يقدر عدد نسخ Gogs المواجهة للإنترنت بحوالي 1,141، ومن المتوقع أن يكون العدد الفعلي أعلى بكثير نظرًا لوجود العديد من عمليات النشر خلف شبكات VPN أو الشبكات الداخلية. عدم وجود تصحيح لهذه الثغرة بعد أكثر من شهرين من الإبلاغ عنها يثير تساؤلات جدية حول أمان الأنظمة التي تعتمد على هذا البرنامج، ويضع المسؤولية على عاتق المستخدمين لتطبيق إجراءات التخفيف اليدوية. يمكن مقارنة هذه الثغرة في خطورتها بغيرها من ثغرات تنفيذ التعليمات البرمجية عن بُعد في خدمات إدارة التعليمات البرمجية، حيث أنها تتيح نقطة دخول مباشرة إلى البنية التحتية الخلفية للمطورين. إن القدرة على التلاعب بالتعليمات البرمجية للمستودعات، سرقة بيانات الاعتماد الحساسة مثل مفاتيح SSH أو رموز الوصول الخاصة بالمطورين، واختراق بيانات مستخدمين متعددين على نفس الخادم، يمثل كابوسًا أمنيًا. هذا النوع من الثغرات يمكن أن يكون نقطة انطلاق لهجمات سلسلة التوريد (supply chain attacks)، حيث يمكن للمهاجم إدخال تعليمات برمجية ضارة مباشرة في مشاريع مفتوحة المصدر أو داخلية، مما يؤثر على عدد كبير من المستخدمين النهائيين.

رؤية Glitch4Techs

من منظور Glitch4Techs، تُظهر هذه الثغرة في Gogs مثالاً صارخًا على المخاطر الكامنة في الاعتماد على البرمجيات مفتوحة المصدر التي قد لا تحظى بدعم وتصحيح سريع. في حين أن الطبيعة المفتوحة للتعليمات البرمجية تتيح الكشف عن الثغرات، إلا أن تأخر الاستجابة من قبل المطورين لتحرير تصحيح يترك المستخدمين في وضع حرج. إن تصنيف CVSS البالغ 9.4 يؤكد على أن هذه ليست مجرد مشكلة عابرة، بل هي عيب جوهري يمكن أن يؤدي إلى اختراق كامل للأنظمة. غياب معرف CVE يزيد من تعقيد تتبع هذه الثغرة وتصنيفها ضمن أنظمة إدارة الثغرات المؤسسية، مما يجعل جهود التخفيف أكثر تحديًا. نرى أن المؤسسات التي تستخدم Gogs يجب أن تتخذ إجراءات فورية لحماية نفسها، نظرًا لتوفر وحدة Metasploit التي تسهل عملية الاستغلال. إن التوصيات المقدمة – تقييد تسجيل المستخدمين، وتقييد إنشاء المستودعات، ومراجعة إعدادات دمج Rebase – هي خطوات أساسية ولكنها قد لا تكون كافية للجميع، خاصة للبيئات التي تتطلب مرونة أكبر. يجب على المسؤولين النظر في بدائل Gogs التي توفر دورة حياة أمنية أكثر قوة، أو على الأقل تطبيق تدقيق صارم ومراقبة مستمرة لأي نشاط غير عادي على خوادم Gogs، خاصة تلك المعرضة للإنترنت. هذه الحادثة تسلط الضوء مرة أخرى على أهمية تقييم مخاطر سلسلة التوريد البرمجية والتأكد من وجود خطط استجابة سريعة للثغرات المكتشفة، حتى في المشاريع مفتوحة المصدر الجديرة بالثقة.