Gitea RCE: ثغرة 9.8 CVSS تتيح تشغيل أوامر Shell عبر Git Hooks

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

تم سد ثغرة تنفيذ تعليمات برمجية عن بعد (RCE) حرجة في Gitea، منصة Git ذاتية الاستضافة، تحمل المعرف CVE-2026-60004 وتقييم CVSS 9.8. تسمح الثغرة لمستخدم يمتلك صلاحيات كتابة عادية على مستودع بتحويل محتوى تصحيح (patch) يتحكم فيه المهاجم إلى Git hook فعال وتشغيل أوامر shell بصلاحيات حساب خدمة Gitea. تؤثر هذه الثغرة على إصدارات Gitea 1.17 والإصدارات الأحدث قبل 1.27.1، وقد تم إصلاحها في الإصدار 1.27.1. تتطلب مكالمة API المعرضة للاستغلال مصادقة وصلاحيات كتابة على المستودع. ومع ذلك، تسمح Gitea بالتسجيل المفتوح افتراضيًا، مما يمكّن أي زائر خارجي من إنشاء حساب عادي ومستودع على تثبيت غير معدّل، ثم استغلال الثغرة دون الحاجة إلى بيانات اعتماد مسبقة. الترقية إلى الإصدار 1.27.1 هي الحل المباشر، وقد أفادت Gitea في 27 يوليو أن أنظمة Gitea Cloud سيتم تحديثها تلقائيًا. بالرغم من أن الإفادة الأمنية الصادرة عن Gitea في 28 يوليو لا تشير إلى استغلال الثغرة في البرية، إلا أنها تتضمن رمز إثبات مفهوم (PoC) عامًا.

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

تكمن الثغرة في نقطة النهاية POST /api/v1/repos/{owner}/{repo}/diffpatch. طبقاً للإفادة الأمنية الصادرة عن Gitea، تقوم نقطة النهاية بتطبيق تصحيح مزوّد داخل نسخة مؤقتة عارية (bare temporary clone) مشتركة. تستدعي الإصدارات المعرضة للاختراق git apply مع الخيارات --index، و--recount، و--cached، و--binary، مضيفةً خيار التراجع ثلاثي الاتجاهات -3 عندما يكون الخادم يعمل بنظام Git 2.32 أو إصدار أحدث. يستغل المهاجم هذا بتقديم نفس التصحيح مرتين لإنشاء تصادم "إضافة/إضافة" (add/add collision). يقوم نظام التراجع ثلاثي الاتجاهات عندئذٍ بالتحقق من المسار المفهرس على الرغم من استخدام --cached. وبسبب طبيعة النسخة المؤقتة العارية، يكون جذرها هو $GIT_DIR. بالتالي، يهبط ملف تنفيذي يُوضع في hooks/post-index-change ضمن دليل Git hook ليصبح نشطًا، ويقوم Git بتشغيله أثناء تحديث الفهرس.

آلية الاستغلال والتبعات

يتضمن إثبات المفهوم (PoC) تسجيل الدخول بحساب عادي، وإنشاء مستودع خاص، وإرسال التصحيح الضار مرتين، ثم استعادة المخرجات. لا يتطلب استدعاءات خارجية؛ يخزن الـhook المخرجات في كائنات Git وينشئ فرعًا بالنتيجة، ليتمكن المهاجم من استعراضها عبر HTTP الذكي الموثق. الاستغلال الناجح يمنح المهاجم امتيازات حساب نظام التشغيل الخاص بـ Gitea. وحسب Gitea، قد يكشف هذا أسرار التطبيق والبيئة، والمستودعات المثبتة، وبيانات اعتماد وقواعد البيانات، وبيانات اعتماد OAuth، والخدمات الداخلية، بناءً على عزل المثيل. تتطلب الثغرة صلاحيات كتابة على المستودع، ونظام Git 2.32 أو أحدث، ومسار diffpatch مُفعّلاً، ونظام ملفات مؤقت قابل للكتابة والتنفيذ. التسجيل الافتراضي المفتوح يمنح المتسلل صلاحيات الكتابة المطلوبة على أي تثبيت غير مُعدّل.

الحل، الذي تم تضمينه في الإصدارات الأقدم (backported) بتاريخ 26 يوليو 2026، كان تغيير Gitea للنسخة المؤقتة من عارية إلى غير عارية. يحذر تعليق الكود صراحةً من أن أوامر Git التي تستخدم --index قد تعمل على شجرة العمل. شُحن الإصدار 1.27.1 في 27 يوليو، وتبعته الإفادة الأمنية في 28 يوليو. أُدرج التغيير في ملاحظات الإصدار تحت بند "MISC" بعنوان "refactor: git patch apply" وليس تحت "SECURITY". كما عرض الباحث شاي رود (NightRang3r) هذه الثغرة مع مشكلة منفصلة لتضمين الملفات (file-inclusion issue) في تغريدة برقم، حيث استرد /etc/passwd من Gitea 1.27.0. تم إصلاح هذه المشكلة ضمن تغيير آخر في 1.27.1 عدّل مُفسّر Org-mode ليعيد مسارات #+INCLUDE كنص عادي، ولم تصدر Gitea إفادة أو CVE منفصلة لها.

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

تُعد Gitea منصة Git ذاتية الاستضافة، وتجذب عادةً المؤسسات الباحثة عن تحكم أكبر في مستودعات التعليمات البرمجية وخطوط أنابيب CI/CD، على النقيض من خدمات SaaS مثل GitHub أو GitLab التي تدير البنية التحتية للمستخدمين. هذا التوجه نحو التحكم الذاتي يلقي بعبء أكبر على عاتق مديري الأنظمة للحفاظ على التكوينات الآمنة. تسلط الثغرة CVE-2026-60004، بتقييم CVSS البالغ 9.8، الضوء على مخاطر التكوين الافتراضي الأساسية: التسجيل المفتوح في Gitea. فبخلاف المنصات الموجهة للمؤسسات، حيث يتم توفير حسابات المستخدمين عادةً بواسطة فرق تكنولوجيا المعلومات، يسمح التكوين الافتراضي لـ Gitea لأي زائر خارجي بإنشاء حساب ومستودع. هذا التراخي الافتراضي يتجاوز بفعالية حاجز المصادقة الأولي الذي كان من شأنه حماية نقطة النهاية POST /api/v1/repos/{owner}/{repo}/diffpatch، محوّلاً ثغرة تبدو وكأنها تتطلب مصادقة إلى ثغرة تنفيذ تعليمات برمجية عن بعد (RCE) يمكن الوصول إليها علناً.

تصعيد التهديد المباشر يأتي من توافر إثبات مفهوم (PoC) عام منذ إفادة Gitea الصادرة في 28 يوليو، مما يحول الثغرة من نظرية إلى قابلة للاستغلال فعليًا. وبينما تمت ترقية أنظمة Gitea Cloud تلقائيًا في 27 يوليو، تظل عمليات النشر ذاتية الاستضافة عرضة للخطر حتى يقوم المديرون بتطبيق الإصدار 1.27.1 يدويًا. يبرز عدم وضوح التصنيف في ملاحظات الإصدار، حيث أُدرج الإصلاح تحت بند "MISC" بعنوان "refactor: git patch apply" بدلاً من "SECURITY"، فشلاً في التواصل قد يؤخر التحديثات الحرجة للعديد من المستخدمين. هذا يتناقض مع الإفادات الأمنية القوية التي تصدرها الشركات الكبرى والتي تعطي الأولوية للتواصل الواضح حول التصحيحات الحرجة. يؤدي الاستغلال الناجح إلى كشف أسرار التطبيقات والبيئة، والمستودعات المثبتة، وبيانات اعتماد قواعد البيانات ومحتوياتها، وبيانات اعتماد OAuth، والخدمات الداخلية التي يمكن الوصول إليها، مما يؤثر على سلامة دورة حياة تطوير البرامج بأكملها في المؤسسات المتضررة. يعد تعطيل التسجيل المفتوح تخفيفًا مؤقتًا لكنه لا يعالج الخلل الأساسي، مما يترك المستخدمين الحاليين ذوي صلاحيات الكتابة معرضين للخطر.

رؤية Glitch4Techs

إن ثغرة Gitea RCE (CVE-2026-60004) ليست مجرد ثغرة حرجة؛ بل هي مثال نموذجي لكيفية تقويض التكوينات الافتراضية للأمن. إن قرار تمكين التسجيل المفتوح افتراضيًا، دون التحقق من البريد الإلكتروني أو موافقة إدارية، يحوّل ثغرة مصادقة عالية الخطورة إلى متجه هجوم عام سهل الاستغلال. يتفاقم هذا الإغفال بسبب التصنيف الغامض للتصحيح بعنوان "refactor: git patch apply" تحت بند "MISC" في ملاحظات إصدار 1.27.1. إن هذا الوصف الضعيف لإصلاح ثغرة RCE بتقييم CVSS 9.8 يظهر نقصًا مقلقًا في نضج التواصل الأمني. يجب على المؤسسات التي تعتمد على Gitea أن تفترض أن أي مثيل مكشوف للعامة يعمل بإصدارات ما قبل 1.27.1 مع تمكين التسجيل الافتراضي هو مثيل مخترق، بغض النظر عن التقارير حول الاستغلال الفعلي في البرية. يؤكد هذا الحادث فشلًا حاسمًا في الموازنة بين سهولة الاستخدام والضوابط الأمنية الافتراضية، مما يفرض مخاطر لا داعي لها على مديري الأنظمة الذين بات عليهم الآن تدقيق سجلات التغييرات بحثًا عن تصحيحات أمنية حرجة متنكرة في هيئة إعادة هيكلة للكود. إن إثبات المفهوم (PoC) العام وسهولة الحصول على الوصول الأولي يجعلان هذا تهديدًا واضحًا ومباشرًا لا يمكن تخفيفه إلا بتحديث سريع ومجبر.