Gitea: استغلال CVE-2026-60004 الحرجة يسقط حمولات تعدين

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

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

يُنسب الفضل في اكتشاف هذه المشكلة الأمنية والإبلاغ عنها للباحث الأمني Shai rod، المعروف أيضاً بـ NightRang3r. تؤثر الثغرة على جميع إصدارات Gitea بدءاً من الإصدار 1.17، وتم توفير التصحيح في الإصدار 1.27.1. هذا التطور يؤكد على الحاجة الماسة لتحديث الخوادم المعرضة للاستغلال على الفور.

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

تتمحور الثغرة (CVE-2026-60004) حول إساءة استخدام نقطة نهاية `diffpatch` الخاصة بـ Gitea. هذه النقطة يمكن التلاعب بها لتثبيت وتنفيذ خطاف Git (Git hook) من محتوى متحكم به بواسطة المستودع نفسه. الخطافات هي سكريبتات يتم تشغيلها تلقائياً عند وقوع أحداث معينة في Git، مثل تلقي دفعة (push) للتعليمات البرمجية. وبوجود صلاحيات الكتابة، يستطيع المهاجم إدخال سكريبت خبيث في هذا الخطاف، والذي يتم تشغيله لاحقاً بامتيازات مستخدم نظام التشغيل الذي يعمل عليه Gitea.

على الرغم من أن استدعاء API المعرض للثغرة يتطلب المصادقة وصلاحيات الكتابة على المستودع، فإن Gitea يسهل هذا الشرط عبر إعدادات التسجيل الافتراضية. هذا يعني أن أي جهة خارجية يمكنها ببساطة إنشاء حسابها الخاص، ومن ثم مستودع جديد، والحصول على صلاحيات الكتابة ضمن هذا المستودع لتنفيذ الاستغلال دون الحاجة إلى اختراق بيانات اعتماد موجودة. وقد أشار المطور Andrey (المعروف أيضاً بـ @Causelof) في تحليل نشر الأسبوع الماضي على منصة Habr الروسية للتدوين، إلى أن خادم Gitea الخاص به كان هدفاً لهجوم استغل CVE-2026-60004 لنشر dropper شبيه ببرنامج تعدين العملات المشفرة. تلقى Andrey إشعاراً من مزود الاستضافة HOSTKEY يفيد بأن خادمه الافتراضي تجاوز 70% من سعة المعالج لفترة طويلة، مما استدعى تقييداً مؤقتاً لموارد وحدة المعالجة المركزية.

كانت إعدادات Gitea للخادم المستهدف حاسمة في تمكين الهجوم:

• `DISABLE_REGISTRATION = false`: يسمح لأي شخص بإنشاء حسابات مستخدمين.
• `REGISTER_EMAIL_CONFIRM = false`: لا يطلب تأكيد التسجيل عبر البريد الإلكتروني، مما يقلل من الاحتكاك للمهاجمين.
• `ENABLE_OPENID_SIGNUP = true`: يسمح بالتسجيل عبر OpenID، مما يوفر مساراً إضافياً.
• `REQUIRE_SIGNIN_VIEW = false`: لا يفرض على المستخدمين تسجيل الدخول لعرض أي صفحة أو استخدام API، مما يسهل الوصول الأولي.

قبل نشر حمولة التعدين، قام سكريبت الـ dropper بخطوات تمهيدية منهجية:

• مسح متغيري البيئة LD_PRELOAD و LD_LIBRARY_PATH لمنع اكتشاف أدوات الأمان.
• البحث عن العمليات ذات الاستخدام العالي لوحدة المعالجة المركزية، غالباً لتحديد وجود برامج تعدين أخرى.
• محاولة إنهاء العمليات المنافسة لضمان أقصى استفادة من الموارد.
• جلب الحمولة الفعلية بناءً على بنية نظام التشغيل المستهدف.
• تنزيل الحمولة وكتابتها إلى موقع مخفي على القرص، ثم تشغيلها.
• حذف ملف الحمولة بعد التنفيذ لمحو آثار الهجوم.

على الرغم من أن الطبيعة الدقيقة للحمولة لم يتم تحليلها بشكل كامل من قبل Andrey، فإن الارتفاع الملحوظ في استخدام وحدة المعالجة المركزية يتوافق بشكل مباشر مع سلوك حملات تعدين العملات المشفرة. الجدير بالذكر أن الهجوم تم عبر HTTPS، حيث لم يكن SSH الخاص بـ Gitea مكشوفاً للعالم الخارجي، مما يؤكد على أن الثغرة يمكن استغلالها عبر واجهة الويب.

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

إن إدراج CISA لهذه الثغرة في كتالوج الثغرات المعروفة المستغلة (KEV) ليس مجرد تحذير، بل هو تفويض إلزامي للوكالات الفيدرالية الأمريكية لتصحيحها بحلول 28 أغسطس 2026. هذا الإجراء يبرز خطورة الثغرة ويصنفها ضمن أولويات الأمن القومي، مما يعكس مستوى التهديد الذي تشكله. في مشهد حلول استضافة التعليمات البرمجية ذاتية الاستضافة، يتنافس Gitea مباشرة مع حلول أكثر تعقيداً مثل GitLab. بينما يوفر GitLab مجموعة واسعة من الميزات المتكاملة لأعباء العمل الكبيرة والمؤسسات، فقد اكتسب Gitea شعبية لكونه خفيف الوزن، سهل النشر، ومفتوح المصدر، مما يجعله مثالياً للفرق الصغيرة والبيئات التي تتطلب حلاً مبسطاً.

ومع ذلك، تكشف ثغرة CVE-2026-60004 أن هذه البساطة يمكن أن تتحول إلى مسؤولية أمنية إذا لم يتم تأمين الإعدادات الافتراضية بشكل استباقي. على عكس GitLab الذي قد يتطلب تكوينات أولية أكثر تعقيداً ولكنها أكثر أماناً، فإن إعدادات Gitea الافتراضية الموجهة نحو “الراحة للمستخدم” قد وفرت للمهاجمين مساراً واضحاً للاستغلال. هذه الثغرة لا تؤثر فقط على سمعة Gitea كمشروع مفتوح المصدر، بل تسلط الضوء أيضاً على الفارق بين سهولة الاستخدام والأمن الافتراضي. إن تكرار حوادث تعدين العملات المشفرة عبر مثل هذه الثغرات يؤكد على أن المهاجمين يستهدفون دائماً أسهل الطرق لتحقيق الربح، مستغلين الإعدادات الافتراضية المتساهلة.

يفرض هذا الحادث على مسؤولي الأنظمة عبئاً أكبر لتدقيق كل تفصيلة في إعدادات التسجيل والمصادقة، مما يحول Gitea من حل “تلقائي” إلى نظام يتطلب تكويناً أمنياً صارماً عند كل نشر.

رؤية Glitch4Techs

إن النهج التصميمي لـ Gitea الذي يسمح بالتسجيل المفتوح افتراضياً، مقترناً بوجود ثغرة حرجة في نقطة نهاية `diffpatch`، لا يمثل مجرد عيب برمجي، بل إخفاقاً معمارياً جوهرياً. إن الحقيقة الصارمة هي أن “الزائر غير المصادق عليه يمكنه الحصول على صلاحيات الكتابة المطلوبة بمجرد إنشاء حساب ومستودع” بفضل إعداد `DISABLE_REGISTRATION = false` الافتراضي. هذا يقلب مبدأ الأمن من أساسه، محولاً أداة تطوير إلى نقطة دخول مباشرة للمهاجمين. إنها ليست مجرد ثغرة يتم إصلاحها، بل قرار تصميمي يدعو صراحةً إلى الاستغلال الانتهازي، كما أكدت حادثة HOSTKEY حيث تجاوز الخادم الافتراضي 70% من استخدام وحدة المعالجة المركزية بسبب حمولة التعدين.

المنظمات التي تعتمد على إعدادات Gitea الافتراضية تعمل بمخاطر متأصلة ومكشوفة بالكامل. المسؤولية عن إنشاء وضع أمني أولي قوي تقع بالكامل على عاتق من يقوم بالنشر والتهيئة، وليس على عاتق منصة Gitea نفسها. هذا الواقع لا يترك مجالاً للتكهنات: إما أن تقوم بتأمينها بنفسك، أو ستتم مهاجمتك.