أصدرت GitLab في 17 أغسطس 2026 تحديثًا أمنيًا طارئًا لمعالجة ثغرة حرجة تؤثر على Community Edition وEnterprise Edition. وتقول الشركة إن الثغرة قد تسمح تحت ظروف معينة لمهاجم غير مصادق عليه بتعديل المشاريع العامة أو حذفها عن بُعد إلى جانب بيانات المستخدمين.
الثغرة تحمل المعرف CVE-2026-19478 وحصلت على تقييم Critical بدرجة 9.4 من 10 وفق CVSS. وقد عالجتها GitLab ضمن الإصدار الأمني الحرج 19.2.4.
#تحديث خارج جدول GitLab المعتاد
وصل التحديث في 17 أغسطس خارج جدول GitLab المعتاد للإصدارات الأمنية المجدولة التي تصدر مرتين شهريًا في الأربعاء الثاني والرابع. وجاء بعد خمسة أيام فقط من إصدار 12 أغسطس الذي تضمن عدة إصلاحات أمنية عالية الخطورة لكن دون أي ثغرة مصنفة Critical.
الإجراء مطلوب فقط من مستخدمي GitLab ذاتي الاستضافة. أما GitLab.com وGitLab Dedicated فهما يعملان بالفعل على الإصدارات المصححة ولا يحتاج عملاؤهما إلى اتخاذ إجراء.
#الإصدارات المتأثرة
تؤثر CVE-2026-19478 على الإصدارات التالية من GitLab CE وEE:
- جميع الإصدارات من
18.2وحتى ما قبل18.11.11 19.0وحتى ما قبل19.0.819.1وحتى ما قبل19.1.619.2وحتى ما قبل19.2.4
الإصلاحات متاحة في 18.11.11 و19.0.8 و19.1.6 و19.2.4. أما الفروع من 18.2 إلى 18.10 فلا يوجد لها إصدار إصلاح منفصل ضمن هذا التحديث لذلك يجب اتباع مسار الترقية المدعوم للوصول إلى إصدار مصحح.
#ماذا تسمح الثغرة للمهاجم بفعله
تصنف GitLab المشكلة على أنها Code Injection مرتبطة بتوجيه داخل GraphQL. وتقول إن مهاجمًا غير مصادق عليه قد يتمكن تحت ظروف معينة من تعديل المشاريع العامة أو حذفها إلى جانب بيانات المستخدمين.
متجه CVSS المنشور يوضح أن الهجوم يمكن تنفيذه عبر الشبكة وبتعقيد منخفض ودون امتلاك أي صلاحيات مسبقة. كما لا يحتاج إلى أي تفاعل من الضحية وهو ما يرفع خطورته بشكل واضح.
GitLab لم تكشف اسم GraphQL directive المتأثر ولم توضح الشروط الدقيقة اللازمة للوصول إلى مسار الاستغلال. لذلك ما زالت التفاصيل التقنية الكاملة محدودة في الوقت الحالي.
حتى 18 أغسطس 2026 لم تعلن GitLab عن استغلال نشط للثغرة. كما لم يظهر علنًا PoC عملي موثوق يثبت الاستغلال رغم ظهور مستودعات مرتبطة بمعرف الثغرة على GitHub.
#ثغرة ثانية في GraphQL
الإصدار نفسه يعالج ثغرة أخرى تحمل المعرف CVE-2026-19650 وصنفتها GitLab بدرجة High مع تقييم 7.1 من 10.
المشكلة عبارة عن Cross-Site Request Forgery في GraphQL multiplex query handler. وتقول GitLab إن ضعف التحقق من الطلبات كان قد يسمح تحت ظروف معينة لمهاجم غير مصادق عليه بتنفيذ mutations عبر طلبات GET.
على عكس الثغرة الحرجة تحتاج CVE-2026-19650 إلى تفاعل من المستخدم حتى ينجح الاستغلال. وتشير قيمة UI:R في متجه CVSS إلى أن الهجوم يعتمد على هذا التفاعل.
الإصدارات المتأثرة بالثغرة الثانية هي نفسها الإصدارات المتأثرة بـ CVE-2026-19478 كما أن الإصلاحات وصلت ضمن الحزم نفسها.
#هل يحتاج التحديث إلى توقف للخدمة
تقول GitLab إن هذه الإصدارات لا تتضمن migrations جديدة. وفي البيئات متعددة العقد لا يتوقع أن يتطلب التحديث توقفًا للخدمة عند اتباع إجراءات الترقية المناسبة.
لكن مستخدمي حزم Omnibus يجب أن ينتبهوا إلى أن عملية التحديث قد توقف الخدمات وتعيد تشغيلها افتراضيًا أثناء تنفيذ خطوات الترقية. لذلك يفضل مراجعة إجراءات التحديث الخاصة بالبيئة قبل البدء.
#التفاصيل التقنية الكاملة قد تتأخر حتى نوفمبر
تقول GitLab حاليًا إنها تجعل القضايا التي تحتوي على التفاصيل الكاملة للثغرات عامة على issue tracker بعد 90 يومًا من إصدار التصحيح. وبالنسبة إلى تحديث 17 أغسطس فهذا يضع موعد الكشف المتوقع قرب 15 نوفمبر 2026.
هذه المدة أطول مما كانت تذكره الشركة قبل أسابيع. فصفحة إصدار GitLab في 10 يونيو 2026 كانت تنص على نشر تفاصيل الثغرات بعد 30 يومًا من إصدار التصحيح.
#ليست أول ثغرة GitLab تجذب الانتباه هذا الصيف
يأتي الإفصاح بعد أسابيع من تقرير نُشر في يوليو 2026 حول ثغرة أخرى في GitLab ذاتي الاستضافة. وفي تلك الحالة نشر باحثون exploit عمليًا بعد أن كانت GitLab قد أصدرت التصحيح في يونيو.
الفرق هنا أن CVE-2026-19478 لا تتطلب حسابًا أو صلاحيات مسبقة وفق متجه CVSS المنشور. ولهذا السبب يجب على مسؤولي GitLab ذاتي الاستضافة التعامل مع التحديث كأولوية وعدم انتظار ظهور تفاصيل الاستغلال الكاملة.
