كشف تقرير أمني حديث عن وجود ثغرة أمنية حرجة في خدمة Gogs، وهي منصة Git ذاتية الاستضافة مفتوحة المصدر، تسمح للمستخدمين المصرح لهم بتنفيذ أوامر برمجية عشوائية.
يُصنف الخلل الأمني، حسب تقييم Rapid7، برقم 9.4 على نظام CVSS، ولم يتم تخصيص معرّف CVE له حتى الآن. يشير هذا التصنيف العالي إلى خطورة الثغرة واحتمالية استغلالها.
ثغرة تنفيذ التعليمات البرمجية عن بعد في Gogs
تتيح هذه الثغرة الأمنية لأي مستخدم مصرح له بالوصول إلى خادم Gogs وتنفيذ تعليمات برمجية عن بعد. يحدث ذلك عند قيام المستخدم بإنشاء طلب سحب (pull request) يحتوي على اسم فرع ضار، والذي يقوم بحقن علامة `–exec` في أمر `git rebase` أثناء عملية الدمج المسماة “إعادة الأساس قبل الدمج” (Rebase before merging).
يُعد `git rebase` عملية هامة في Git تُستخدم لتطبيق سلسلة من التعديلات من فرع إلى آخر، بهدف إنشاء سجل تاريخي خطي للمشروع. وعلى الرغم من أن `git rebase` يخدم نفس غرض `git merge` في دمج التغييرات، إلا أنه يعيد كتابة التاريخ بإنشاء التزامات (commits) جديدة لكل تعديل في الفرع الأصلي.
من الجدير بالذكر أن عملية `git rebase` تقبل أيضاً أمراً نصياً كمعامل عبر علامة `–exec`، والذي يتم تنفيذه بعد إعادة كل التزام. أحد الجوانب البارزة لهذه الثغرة هو أنها لا تتطلب امتيازات إدارية أو تفاعلاً مع مستخدمين آخرين.
آلية استغلال الثغرة
للتغلب على هذه الثغرة، كل ما يحتاجه المهاجم غير المصرح له هو إنشاء حساب ومستودع برمجيات (repository) على أي نسخة افتراضية الإعدادات من Gogs. ففي النسخ الافتراضية، يصبح المستخدم الذي ينشئ مستودعاً هو مالكه تلقائياً.
من هناك، يكون تفعيل دمج إعادة الأساس (rebase merging) مجرد تبديل بسيط في الإعدادات، ويمكن للمهاجم تشغيل سلسلة الاستغلال بالكامل دون الحاجة إلى أي تفاعل من مستخدم آخر. وهذا يجعل اكتشاف الهجمات وتتبعها أكثر صعوبة.
في سيناريو بديل، يمكن للمستخدم الذي لديه صلاحية الكتابة (write access) لمستودع برمجي تم تفعيل إعادة الأساس فيه بالفعل، استغلال الثغرة مباشرة للحصول على تنفيذ التعليمات البرمجية. أما في حالات Gogs التي تكون فيها عملية إنشاء المستودعات مقيدة، فيتطلب الأمر أن يكون للمهاجم صلاحية الكتابة في أي مستودع برمجي تم فيه تفعيل دمج إعادة الأساس.
وحتى لحظة كتابة هذا التقرير، لم يتم إصدار أي تصحيح لهذه الثغرة، على الرغم من الإبلاغ عنها للصيانة في 17 مارس 2026. يمكن أن يمنح الاستغلال الناجح لهذه المشكلة المهاجم القدرة على اختراق الخادم، والوصول إلى جميع المستودعات على النسخة، وسرقة بيانات الاعتماد، والانتقال إلى أنظمة أخرى يمكن الوصول إليها عبر الشبكة، والتلاعب بكود أي مستودع مستضاف.
والأخطر من ذلك، يمكن أن تؤدي الثغرة إلى خرق بيانات عبر عدة مستخدمين (cross-tenant data breach)، مما يسمح للمهاجم بقراءة المستودعات الخاصة لمستخدمين آخرين مستضافين على نفس الخادم المشترك. وفقاً لـ Rapid7، تؤثر هذه الثغرة على جميع المنصات المدعومة، بما في ذلك أنظمة التشغيل Windows و Linux و macOS.
يقدر عدد النسخ المتصلة بالإنترنت من Gogs بحوالي 1,141 نسخة. ومع ذلك، من المتوقع أن يكون الرقم الفعلي أعلى، نظراً لأن معظم عمليات النشر تكون خلف شبكات VPN أو داخل الشبكات الداخلية.
توصيات الحماية في ظل غياب التصحيح
في غياب تصحيح رسمي، توصي Rapid7 باتخاذ الإجراءات الاحترازية التالية:
- تقييد تسجيل المستخدمين (تعيين `DISABLE_REGISTRATION = true` في ملف `app.ini`) لمنع المستخدمين غير الموثوق بهم من إنشاء حسابات.
- تقييد إنشاء المستودعات (تعيين `MAX_CREATION_LIMIT = 0` في ملف `app.ini`) لمنع المستخدمين من إنشاء مستودعاتهم الخاصة.
- مراجعة إعدادات دمج إعادة الأساس (rebase merge settings) للتأكد من أنها ليست عرضة للاستغلال.
أصدرت Rapid7 أيضاً وحدة Metasploit تعمل على أتمتة سلسلة الاستغلال بالكامل ضد أهداف Linux و Windows. تدعم الوحدة وضعين: الوضع الافتراضي حيث يتم إنشاء مستودع مؤقت تحت حساب المهاجم، ثم تشغيل الاستغلال، وأخيراً حذف المستودع. النهج الثاني يستهدف مستودعاً يمتلك المهاجم بالفعل صلاحية الكتابة والدمج له.
يشير الخبراء إلى أنه عند قيام المهاجم بإنشاء وحذف المستودع الخاص به، لا يترك ذلك سوى أثر HTTP 500 في سجلات الخادم. أما عند استغلال مستودع موجود، فإن آثاراً إضافية قد تبقى.