CVE-2026-85706 — CVSS 10.0, اجتياز مسار غير مصادق عليه
CVE-2026-85706 ثغرة اجتياز مسار في مكوّن إدارة المستودعات في GitLab CE وEE. متجه CVSS هو AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — لا مصادقة مطلوبة، ولا تفاعل مع المستخدم، وتأثير كامل على السرية والنزاهة والتوافر. عملياً، يتيح طلب HTTP مشوَّه موجَّه إلى نقطة نهاية API أرشيفات المستودع للمهاجم اجتياز نظام ملفات نسخة GitLab والوصول إلى ملفات الإعدادات الحساسة خارج جذر المستودعات. نشر باحث watchTowr إثباتاً للمفهوم يعمل بعد وقت قصير من الإفصاح، وأكدت فرق Rapid7 وجود محاولات استغلال نشطة في بيانات ETR. أدرجت CISA CVE-2026-85706 في كتالوج الثغرات المستغلة المعروفة في العاشر من سبتمبر 2026.
ما يمكن للمهاجم قراءته عبر اجتياز المسار
- secrets.yml — يحتوي على مفتاح التشفير active_record_encryption وبذور الرموز الداخلية؛ يتيح اختراقه فك تشفير قاعدة بيانات GitLab بأكملها
- مفاتيح SSH الخاصة بـ runners الخاصة بـ GitLab CI/CD — تتيح تنفيذ الأوامر على عوامل البناء والتمحور نحو بيئات النشر
- رموز CI/CD ومتغيرات البيئة المخزنة في الإعدادات — مفاتيح السحاب، مفاتيح API، أسرار النشر المُحقَنة في خطوط الأنابيب
- ملفات إعداد قاعدة البيانات (database.yml) — المضيف والمنفذ واسم القاعدة وبيانات اعتماد اتصال PostgreSQL
- بيانات جلسة Redis إذا كانت الإعدادات تشير إلى مقبس Unix يمكن الوصول إليه
- محتوى أي ملف يمكن لمستخدم النظام git قراءته في شجرة النسخة
من يتأثر — ومن لا يتأثر
إصدارات GitLab CE وEE من 18.7.0 إلى 19.3.1 شاملةً قابلة للاستغلال، سواء مُثبَّتة عبر حزم omnibus أو مُنشَرة كحاوية Docker أو مُنشَرة عبر Helm على Kubernetes. خدمة GitLab.com (الخدمة السحابية التي تستضيفها شركة GitLab Inc.) جرى تصحيحها مسبقاً من قِبَل فريق GitLab قبل الإفصاح العلني — مستخدمو GitLab.com غير متأثرين ولا يحتاجون إلى أي إجراء. النسخ المستضافة ذاتياً فقط هي المعرَّضة. إصدارات GitLab السابقة للإصدار 18.7 غير متأثرة بهذا المتجه تحديداً، لكنها منتهية الدعم ومعرَّضة لثغرات أخرى غير مُصحَّحة. النسخ المعزولة خلف جدار حماية أو VPN ليست محمية: المتجه هو HTTP على المنفذَين 80 و443، ويكفي وصول شبكي داخلي لتشغيل الاستغلال.
تصحيح GitLab CE/EE إلى الإصدار 19.3.2
نسخ احتياطي للنسخة قبل أي عملية
شغِّل نسخاً احتياطياً كاملاً:
sudo gitlab-backup create STRATEGY=copy. تحقق من وجود الأرشيف في /var/opt/gitlab/backups/ وانسخه إلى تخزين خارجي. لا تتخطَّ هذه الخطوة حتى في حالات الطوارئ.إيقاف GitLab وتحديث حزمة omnibus
على Debian/Ubuntu:
sudo gitlab-ctl stop && sudo apt-get update && sudo apt-get install --only-upgrade gitlab-ee=19.3.2-ee.0 && sudo gitlab-ctl reconfigure && sudo gitlab-ctl start. على RHEL/CentOS: استبدل apt-get بـ yum update gitlab-ee-19.3.2. تحقق من الإصدار بعد إعادة التشغيل: sudo gitlab-rake gitlab:env:info | grep GitLab.تحديث نسخة Docker
اسحب الصورة الجديدة:
docker pull gitlab/gitlab-ee:19.3.2-ee.0. أوقف الحاوية الموجودة: docker stop gitlab. أعد تشغيلها بالصورة الجديدة مع الإبقاء على وحدات التخزين المُثبَّتة. انتظر اكتمال إعادة الضبط التلقائي قبل اختبار الوصول.التحقق من سلامة ما بعد التحديث
شغِّل فحوصات الصحة المدمجة:
sudo gitlab-rake gitlab:check SANITIZE=true وsudo gitlab-rake gitlab:doctor:secrets. إذا أفاد أيٌّ منهما بخلل في secrets.yml، فأجرِ فوراً تدوير الأسرار الموضَّح في القسم التالي.
تدوير الأسرار بعد التعرض المحتمل
إذا كانت نسختك مكشوفة على الإنترنت بين إصدار الإصدار 18.7 وتطبيق التصحيح — أو إذا كان لديك أدنى شك — فإن تدوير الأسرار إلزامي. التصحيح يوقف الاستغلال المستقبلي لكنه لا يُلغي بيانات الاعتماد التي جرى اختراقها. ابدأ بإعادة توليد مفتاح تشفير قاعدة البيانات: sudo gitlab-rake gitlab:encrypted_secrets:rotate_key. ثم ألغِ وأعد توليد جميع رموز runners CI/CD من واجهة الإدارة، وأعد ضبط كل عامل runner بالرمز الجديد. استبدل مفاتيح SSH المُنشَرة على runners. راجع متغيرات CI/CD في كل مشروع وغيِّر جميع أسرار النشر.
قائمة التحقق بعد التصحيح
- تأكيد الإصدار المُثبَّت:
sudo gitlab-rake gitlab:env:info | grep 'GitLab version' يجب أن يُظهر 19.3.2 - البحث عن مؤشرات الاختراق في سجلات Nginx: أنماط طلبات تحتوي
../ مكرراً أو مشفَّراً - التحقق من اتصالات SSH غير متوقعة في /var/log/auth.log منذ تثبيت الإصدار 18.7
- فحص النسخة بأداة الكشف التي نشرها watchTowr لتأكيد إغلاق المتجه
- تفعيل المصادقة الثنائية الإلزامية لجميع حسابات المشرفين
- التحقق من إرسال ترويسات أمان HTTP بشكل صحيح بعد التحديث
- جدولة تدقيق أمني لصلاحيات المستودعات — قد يكون الاستغلال الناجح أنشأ حسابات مشرف مخفية
بديل: الهجرة إلى Gitea على VPS للحد من سطح الهجوم
GitLab CE منصة Git متكاملة لكن بنيتها المتجانسة وقاعدة كودها الضخمة بـ Ruby on Rails توسّعان سطح الهجوم ميكانيكياً. CVE-2026-85706 ليست حادثةً معزولة: شهد GitLab أربع ثغرات حرجة (CVSS ≥ 9.0) خلال الثمانية عشر شهراً الماضية. Gitea بديل مكتوب بـ Go في ملف تنفيذي واحد بصمة ذاكرته أصغر بعشر مرات تقريباً وتاريخه في الثغرات الحرجة أقصر بكثير. على خادم VPS بصلاحية root، تحتفظ بالتحكم الكامل في جدول التحديث والنسخ الاحتياطية وتدوير الأسرار دون الاعتماد على طرف ثالث. للفرق التي تحتاج أساساً إلى استضافة Git وطلبات السحب والـwebhook وتكامل CI خفيف، يوفر Gitea الأساسيات مع سطح هجوم أصغر بكثير. تشمل الهجرة تصدير المستودعات والـissues والـwiki والأعضاء من GitLab عبر الـAPI ثم استيرادها في Gitea — عملية موثقة في مقال الهجرة المخصص.
نشر Gitea على VPS ServOrbit في 4 خطوات
تهيئة VPS واختيار قالب Gitea
من بوابة العميل ServOrbit، أنشئ VPS جديداً (2 نواة على الأقل، 2 غيغابايت RAM لفريق يصل إلى 20 مطوراً) واختر قالب تطبيق Gitea. يهيئ القالب Gitea مع systemd ووكيل عكسي Nginx مع TLS تلقائي ونسخاً احتياطياً يومياً.
ضبط النطاق وTLS
وجِّه نطاقك الفرعي إلى IP الخادم عبر سجل A. يكتشف نص ما بعد التثبيت النطاقَ ويطلب شهادة Let's Encrypt ويهيئ Nginx على HTTPS فقط مع HSTS.
استيراد المستودعات من GitLab
يتضمن Gitea معالج هجرة مدمجاً يقبل عنوان نسخة GitLab ورمز وصول شخصي. يستورد المستودعات والفروع والوسوم والمشكلات المفتوحة والويكيات. لأنظمة واسعة، يتيح
gitea-cli migrate أتمتة الاستيراد دُفعياً.ضبط runners CI/CD وإلغاء النسخة القديمة
انشر Forgejo Actions أو وصِّل عامل Gitea Act. حدِّث أسرار النشر في كل مستودع مُهاجَر. بمجرد التحقق من صحة خطوط الأنابيب على Gitea، ألغِ رموز نسخة GitLab القديمة وجدوِل إزالة GitLab لتحرير الموارد.
للنسخ الموجودة خلف VPN أو شبكة داخلية: لا تؤجل التصحيح بافتراض أن العزل الشبكي كافٍ. متجه CVE-2026-85706 هو HTTP على المنفذَين 80 و443 — أي مستخدم لديه وصول إلى VPN أو أي جهاز مخترق على الشبكة الداخلية يمكنه تشغيل الاستغلال دون أي بيانات اعتماد GitLab. التصحيح هو العلاج الوحيد الموثوق.
GitLab CE المستضاف ذاتياً مقابل Gitea — معايير الأمان والتشغيل
مرّر الجدول أفقيًا
| المعيار | GitLab CE 19.x | Gitea 1.22.x |
|---|---|---|
| اللغة / المعمارية | Ruby on Rails + Go (هجين) | Go — ملف تنفيذي واحد |
| الحد الأدنى لبصمة الذاكرة | ~2–4 غيغابايت RAM | ~150–300 ميغابايت RAM |
| ثغرات حرجة (CVSS ≥ 9) خلال 18 شهراً | 4 منها CVE-2026-85706 | 0 |
| مصادقة ثنائية مدمجة | نعم | نعم |
| التحكم في جدول التصحيح | أنت (استضافة ذاتية) | أنت (استضافة ذاتية) |
| خدمة سحابية مُصحَّحة مسبقاً | GitLab.com (مجاني) | Gitea Cloud (تجريبي) |
| تكامل CI/CD أصلي | GitLab CI (كامل) | Gitea Actions / Forgejo Actions |
| الهجرة من GitLab | غير منطبق | معالج مدمج + API |
درس أمني: إدارة منصة Git على VPS بصلاحية root
توضح CVE-2026-85706 مبدأً أساسياً في أمن البرمجيات المستضافة ذاتياً: نافذة التعرض بين الكشف عن ثغرة حرجة وتطبيق التصحيح هي الفترة الأخطر في حياة النسخة. على GitLab.com، كانت هذه النافذة معدومة — صحَّح فريق GitLab بصمت قبل الإفصاح. على نسخة مستضافة ذاتياً، تعتمد النافذة كلياً على قدرتك على تلقّي التنبيه والاختبار والنشر بسرعة. VPS بصلاحية root يمنحك التحكم الكامل في هذه الدورة. على VPS ServOrbit، تتيح النسخ الاحتياطية التلقائية والوصول المباشر بصلاحية root الوفاءَ بهذا الجدول الزمني دون الاعتماد على خدمة مُدارة لا تتحكم في مواعيدها ولا إجراءاتها. يمكنك أتمتة تحديثات الأمان عبر unattended-upgrades، وجدولة النسخ الاحتياطية اليومية، وتدوير الأسرار فور الحاجة — دون انتظار موافقة مزود الخدمة أو نافذة صيانة مجدولة مسبقاً لا تتحكم فيها.
