كشفت شركة Aikido Security عن سلوك أمني بالغ الخطورة في منصة GitLab، حيث يمكن لأي شخص يحصل على البريد الإلكتروني الخاص بإنشاء المهام (Issues) أن يستغلّه كـ”اعتماد” مباشر، ليقوم بدفع الشيفرة البرمجية وتنفيذ وظائف CI/CD باسم صاحب الحساب، دون الحاجة إلى كلمة مرور أو مفتاح مصادقة أو حتى المرور بآليات التحقق الثنائية.
كيف يعمل البريد كاعتماد؟
يوفر GitLab لكل مستخدم عنوان بريد خاص خلف زر “Email work item to this project”، ويُستخدم عادةً لإرسال تقارير أو مهام جديدة. لكن هذا البريد يحتوي على رمز مميز (Token) مرتبط بالحساب، ولا تنتهي صلاحيته وفقاً لتوثيق GitLab. المشكلة أن هذا الرمز لا يقتصر على مشروع واحد، بل ينطبق على جميع المشاريع التي يمكن للمستخدم الوصول إليها، سواء كانت عامة أو خاصة. والأسوأ أن GitLab لا يتحقق من هوية المرسل، ما يعني أن أي شخص يملك العنوان يمكنه إرسال تعليمات تُنفذ بصلاحيات صاحب الحساب.
من فتح الثغرة إلى السيطرة على الشيفرة
أظهرت Aikido أن تغيير لاحقة البريد من -issue إلى -merge-request يحوّل الرسالة إلى طلب دمج. عند إرفاق ملف تعديل (Patch) وتحديد الفرع المستهدف في عنوان الرسالة، يقوم GitLab بدمج التعديل مباشرة في ذلك الفرع باسم المستخدم الأصلي. إذا كان الفرع هو main أو أي فرع محمي يمكن للمستخدم الوصول إليه، فإن التعديل يهبط مباشرة هناك. والأسوأ أن أي تعديل في ملف .gitlab-ci.yml يؤدي إلى تشغيل وظائف CI/CD بصلاحيات المستخدم، ما يفتح الباب أمام تنفيذ تعليمات خبيثة داخل بيئة التطوير.
عوامل تحد من الخطورة
- صلاحيات الرمز لا تتجاوز صلاحيات الحساب الأصلي، ما يعني أن حساب “Guest” لا يمثل خطراً كبيراً، بينما حساب “Maintainer” يتيح وصولاً واسعاً.
- يحتاج المهاجم إلى معرفة مسار المشروع ومعرّفه الرقمي (ID)، وهو ما يتوفر علناً في المشاريع العامة، بينما يتطلب تسريباً إضافياً في المشاريع الخاصة.
لكن رغم هذه القيود، فإن الثغرة تتجاوز قيود الشبكة وقوائم السماح (IP allowlist)، كما تتخطى التحقق الثنائي (2FA)، لأن البريد الوارد معفى من هذه الضوابط وفقاً لتوثيق GitLab.
ما الذي يجب فعله؟
- إعادة تعيين رمز البريد الوارد من صفحة Personal Access Tokens في الملف الشخصي، حيث يؤدي ذلك إلى إبطال جميع العناوين السابقة.
- مراجعة ملفات README وأدلة المساهمة وصفحات الدعم للتأكد من عدم نشر هذه العناوين علناً.
- على النسخ المُدارة ذاتياً، يمكن للمسؤولين تعطيل ميزة البريد الوارد بالكامل.
- تغيير جميع الرموز السرية إذا كان هناك شك في تسريب البريد.
موقف GitLab
أفادت Aikido أنها أبلغت GitLab عبر منصة HackerOne في مايو 2026، لكن البلاغ أُغلق باعتباره “سلوكاً مقصوداً”. لاحقاً، أُعيد فتح القضية بشكل سري في يونيو. موقف GitLab الرسمي هو أن هذا البريد يُعامل كرمز اعتماد، وأي تسريب يؤدي بالضرورة إلى نتائج خطيرة، تماماً مثل تسريب أي مفتاح وصول آخر. مع ذلك، غيّرت GitLab وصف الميزة لتشير صراحة إلى أنها تتيح إنشاء Issues وMerge Requests، بعدما كانت تصفها فقط بأنها لإنشاء “Work Items”.
هذا السلوك يضع آلاف المشاريع أمام خطر حقيقي، ويؤكد أن إدارة الاعتمادات في منصات التطوير يجب أن تُعامل بحذر شديد، خاصة عندما تكون مرتبطة بآليات البريد الإلكتروني التي يسهل تسريبها أو نشرها عن غير قصد.
