سمح AI Gateway من GitLab لإعداد Flow مُصمَّم بالخروج من صندوق الرمل الخاص بالمطالبات.

في 2 أكتوبر 2026، نشرت GitLab إصدار تصحيح حرج لـ AI Gateway — الوسيط الذي ينقل الطلبات بين نسخة GitLab ونماذج اللغة التي تستدعيها ميزات Duo — وسمّته CVE-2026-90970 وصنّفته 9.9 من 10. ووفقاً لكلمات GitLab نفسها، كان الخلل قد يسمح "لمستخدم مُصادَق عليه لديه وصول إلى Duo Agent Platform بالهروب من بيئة عزل قوالب الموجّهات عبر إعداد تدفّق مُصمَّم خصيصاً، مما يؤدي إلى تنفيذ أوامر تعسفية على AI Gateway." ولم تكن بحاجة إلى التحرّك سوى المؤسسات التي تشغّل بوابة AI Gateway مستضافة ذاتياً: فقد كانت GitLab قد أصلحت بالفعل البوابات التي تديرها لـ GitLab.com وGitLab Dedicated والعملاء ذوي الإدارة الذاتية الذين يستخدمون بوابة مستضافة من GitLab، وأعلنت ذلك في التنبيه. ولا يذكر إشعار GitLab أن الخلل قد استُغلّ يوماً ما، كما أن التقييم المرفق بسجل CVE من وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية في اليوم نفسه يدرج الاستغلال بوصفه "none". وعاد الفضل في الاكتشاف إلى باحث HackerOne المعروف باسم invisiblemeerkat. يتّسق تنبيه GitLab وسجل NVD والتقارير التي تلته مع بعضها بعضاً بشأن ماهية الخلل والإصدارات التي حملته؛ وهي متّسقة بالقدر نفسه بشأن ما ليس معروفاً، وهو ما إذا كان أي شخص قد استخدمه يوماً. ويأتي هذا السجل إلى جانب الثغرات الأخرى الموثّقة في البنية التحتية للوكلاء في أرشيف حوادث الذكاء الاصطناعي، حيث يحمل كل مدخل مصادره ودرجة خطورته ودرجة ثقته وعلامة كونه محل نزاع.

ما الذي يقوله التحذير فعليًا، وما الذي يغفله

التنبيه موجز. نُشر على موقع توثيق GitLab بعنوان «إصدار تصحيحي حرج لـ GitLab AI Gateway: 19.2.4 و19.3.2 و19.4.1»، ويسرد إصلاحًا أمنيًا واحدًا بعنوان «مشكلة تحييد غير سليم في قالب موجه التدفق المخصص تؤثر على AI Gateway»، ومصنّفًا بدرجة حرج. ويورد متجه CVSS 3.1 على النحو التالي: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — يمكن الوصول إليه عبر الشبكة، وتعقيد الهجوم منخفض، والامتيازات المطلوبة منخفضة، ولا يتطلب تفاعل المستخدم، والنطاق متغيّر، والتأثير مرتفع على السرية والسلامة والتوافر. يستحق هذا المتجه القراءة لأنه دقيق بشأن المهاجم: امتيازات منخفضة، لكنها امتيازات مع ذلك. يقول التنبيه «مستخدم موثّق لديه صلاحية الوصول إلى Duo Agent Platform» ثم يتوقف عند هذا الحد. ولا يسمّي الدور أو الإذن أو الظروف التي تشير إليها عبارته الخاصة «في ظل ظروف معينة».

إنه لا ينشر إثبات مفهوم، ولا يصف إعداد التدفق المصمم، ولا يقدم حلًا بديلًا للبوابات التي لا يمكن تحديثها على الفور. وتلاحظ Hacker News في تقريرها الصادر في 2 أكتوبر الغيابات نفسها، وتضيف غيابًا مهمًا من الناحية التشغيلية: فلا يقدم التنبيه الأمني أي وسيلة للتحقق مما إذا كانت البوابة قد تعرضت لهجوم قبل تثبيت الرقعة. وتسجل Security Affairs، في كتابتها في اليوم التالي، الفجوات نفسها.

إن مدخل تعداد نقاط الضعف الشائعة المرفق بـ CVE هو CWE-1336، أي التحايد غير السليم للعناصر الخاصة المستخدمة في محرك قوالب. ولا يستخدم تنبيه GitLab كلمة Jinja مطلقًا. أما وثائق مستودع AI Gateway نفسه فتستخدمها: إذ تصف وثيقة سجل المطالبات الخاصة به ملفات تكوين المطالبات بأنها "تدعم تعبير Jinja لأدوار متعددة مثل المستخدم والنظام"، وتصف فئة Prompt بأنها "تستخدم Jinja لاستبدال قوالب المطالبات بوسائط الإدخال". والثغرة التي يصفها CVE هي تلك التي يشتهر بها هذا النوع من المحركات — وصول نص يقدمه المستخدم إلى قالب تتم تقييمه بدلًا من طباعته.

لماذا يستحق أمرٌ على هذا المضيف تحديدًا 9.9

AI Gateway ليس مكوّن sidecar. وفقًا لوثائق GitLab للاستضافة الذاتية، فإنه يتلقى الطلبات من GitLab، ويجمّع المطالبات، ويتواصل مع الواجهة الخلفية للنموذج — خادم vLLM أو Amazon Bedrock أو Azure OpenAI أو مزوّد خارجي — وفي نشر مستضاف ذاتيًا بالكامل يكون هو المكوّن الذي يُبقي المطالبات والردود داخل شبكة المؤسسة الخاصة. كما يوجّه دليل تثبيت AI Gateway من GitLab المسؤولين إلى إنشاء زوج مفاتيح توقيع وتمرير الجزأين إلى الخدمة كمتغيرات بيئة، باسم AIGW_SELF_SIGNED_JWT__SIGNING_KEY وAIGW_SELF_SIGNED_JWT__VALIDATION_KEY (مع مكافئات Duo Workflow). ويوضح Security Affairs النتيجة صراحةً: أن تنفيذ الأوامر على البوابة يضع المهاجم على مضيف يحتفظ بمواد توقيع JWT ويقع على المسار بين نسخة GitLab والبنية التحتية للنموذج.

هذا هو الفرق بين الهروب من بيئة العزل في نموذج تجريبي والهروب منها في بيئة الإنتاج. لا يحتاج الهروب إلى الوصول إلى نموذج؛ بل يحتاج إلى الوصول إلى العملية التي تحتفظ بالمفاتيح التي تُوقَّع بها نداءات النموذج.

توثيق منتج GitLab، بصورة منفصلة عن التنبيه الأمني، ينص على أن إنشاء تدفق مخصص أو تحريره يتطلب دور Maintainer أو Owner في المشروع المُدير، وأن تشغيل أحدها يتطلب دور Developer أو أعلى. ولا يؤكد التنبيه الأمني ذلك الربط، وتشير The Hacker News إلى أنه لا يُسمّى أي دور يتجاوز "الوصول إلى Duo Agent Platform". وينبغي للقارئ الذي يقدّر مدى تعرضه أن يعامل التوثيق بوصفه نموذج الأذونات الخاص بالمنتج، وأن يعامل صمت التنبيه الأمني على أنه صمت فحسب: لا تناقض.

مُثبَت، وغير مُثبَت

حقول السجل نفسها متسقة مع كل ما سبق ولا تضيف شيئًا غير موجود في المذكرة الإرشادية. وما يلي هو التفصيل الذي لا يستطيع القارئ الحصول عليه من ملخص من سطر واحد.

• مُثبت: ثغرة بالغة الخطورة في GitLab AI Gateway، أُفصح عنها في 2 أكتوبر 2026، بدرجة CVSS 9.9، وCWE-1336، يمكن الوصول إليها من قِبل مستخدم مُصادَق عليه في Duo Agent Platform عبر إعداد تدفق مُصمَّم خصيصًا، مما يؤدي إلى تنفيذ أوامر على مضيف البوابة.

• تم تحديد: النطاق المتأثر — جميع إصدارات AI Gateway من 18.1.6 قبل 19.2.4، و19.3 قبل 19.3.2، و19.4 قبل 19.4.1 — والإصدارات المُصلحة، 19.2.4 و19.3.2 و19.4.1.

• مؤكد: تم ترقيع البوابات المستضافة لدى GitLab قبل النشر ولا يحتاج عملاؤها إلى اتخاذ أي إجراء؛ كما تم التواصل مباشرة مع مشغّلي الاستضافة الذاتية قبل نشر منشور الإصدار، وهو ما تذكره GitLab في الإشعار نفسه.

• المُثبت: نسبة الفضل في الإبلاغ إلى invisiblemeerkat، وغياب أي بيان عن استغلاله في البرية.

• لم يُثبَت:ما إذا كان أي شخص قد استغلها. يصنّف تقييم CISA SSVC المؤرخ 2 أكتوبر 2026 والظاهر في سجل NVD الاستغلال بأنه «لا شيء»، والقابلية للأتمتة بأنها «لا»، والتأثير التقني بأنه «كلي»؛ ولم يُدرِج كتالوج CISA Known Exploited Vulnerabilities الثغرة CVE-2026-90970 في مراجعته المؤرخة 20 أكتوبر 2026، وهو ما تحققت منه مباشرة. وقد وضع نموذج FIRST EPSS احتمال الاستغلال خلال الأيام الثلاثين التالية عند 0.94 بالمئة في 21 أكتوبر 2026 — منخفض، وليس صفرًا.

• غير مؤكد: عدد البوابات المستضافة ذاتيًا الموجودة، وعدد ما كان منها مكشوفًا، أو ما إذا كان أيٌّ منها قد تعرّض للهجوم قبل الترقيع. لا يقدّم أي مصدر في هذا السجل عددًا، ولا يتضمّن إشعار GitLab أي طريقة للكشف.

النطاق المتأثر، والإصدارات التي لم تُدرج لها إصلاحات

إن حساب الإصدارات أقل إحكامًا مما توحي به الإصدارات الثلاثة المُصلحة. يبدأ النطاق المتأثر عند 18.1.6، ولا يُنشر أي إصدار مُصلح على أي خط إصدار أدنى من 19.2.4. وعليه، تقع كل بوابة من 18.1.6 وحتى سلسلة 19.1 داخل النطاق المتأثر المعلن، دون تسمية نسخة مُرقّعة لها. وتنبه Hacker News إلى النتيجة نفسها وإلى الأسئلة التي تليها: تُخبر وثائق تثبيت GitLab المسؤولين بتشغيل صورة البوابة التي يطابق إصدارها الإصدار الثانوي من GitLab لديهم، ولا يوضح التنبيه ما إذا كانت بوابة 19.2.4 تعمل مع GitLab 19.1 أو إصدارات أقدم، ولا ما إذا كانت هناك إصلاحات مخطط لها للخطوط الأقدم. وتُدرج سياسة الإصدارات المدعومة في GitLab، كما تلاحظ Hacker News، حاليًا 19.4 و19.3 و19.2 — وهي الخطوط الثلاثة نفسها التي تلقت إصلاحات.

تتمثل المعالجة في استبدال الحاوية بدلًا من تطبيق رقعة: إذ تُشحن البوابة كصورة Docker خاصة بها أو كمخطط Helm مستقل. ويوضح دليل التثبيت الخاص بـ GitLab خطوات إيقاف الحاوية العاملة وإزالتها، وسحب الصورة الجديدة ذات الوسم self-hosted-vX.Y.Z-ee، ثم تشغيلها من جديد مع الحفاظ على متغيرات البيئة كما هي؛ أما عمليات النشر عبر Helm فتُعيّن الوسم في حقل image داخل المخطط. ولا تقدّم الاستشارة الأمنية ولا دليل التثبيت أي توقيع أو مؤشر يميّز بوابة تعرّضت للهجوم من بوابة سليمة.

نفس فئة الأخطاء، قبل ثمانية أشهر

ليست هذه المرة الأولى التي تصدر فيها GitLab تقييم 9.9 لثغرة حقن القوالب في AI Gateway. في 6 فبراير 2026، أصدرت AI Gateway 18.6.2 و18.7.1 و18.8.1 بشأن CVE-2026-1868، التي وُصفت في ذلك التنبيه بأنها "مشكلة توسيع قالب غير آمن" حيث كان مكوّن Duo Workflow Service "عرضةً لتوسيع قالب غير آمن لبيانات يوفّرها المستخدم عبر تعريفات Duo Agent Platform Flow المصممة ببراعة"، ويمكن استخدامها لحرمان الخدمة أو تنفيذ الشيفرة على البوابة. إن متجه CVSS مطابق لمتجه أكتوبر، حرفًا بحرف، وكذلك CWE. وكان المبلّغ مختلفًا: فقد اكتُشفت تلك الثغرة داخليًا، بواسطة عضو فريق GitLab Joern Schneeweisz.

لا يذكر التنبيه الصادر في أكتوبر التنبيه الصادر في فبراير، وقد صرّحت The Hacker News بذلك صراحةً. أما ما إذا كان الاثنان يتشاركان سببًا جذريًا واحدًا، أو إصلاحًا لم يصمد، أو مجرد لغة ونموذج تهديد، فليس هذا ما تجيب عنه أي من الوثيقتين العامتين. وما هو مسجّل أن محرك قوالب في مكوّن وسيط للذكاء الاصطناعي قد أنتج الآن تنبيهين حرجين بشأن تنفيذ الأوامر بالتقييم نفسه في السنة نفسها، وأن الثاني استلزم باحثًا خارجيًا للعثور عليه.

ما الذي تغيّر، وما الذي بقي للمشغّلين ليقرّروه

التغيير الملموس هو ثلاثة وسوم للصور وجولة تواصل مباشر. تقول GitLab إنها تواصلت مع عملاء البوابة المستضافة ذاتيًا قبل النشر، وصدر التنبيه إلى جانب الصور المُصلحة في اليوم نفسه. أما بالنسبة إلى الجميع الآخرين — GitLab.com وGitLab Dedicated والنُسخ المُدارة ذاتيًا الموجّهة إلى بوابة تستضيفها GitLab — فقد كان الإصلاح قد طُبّق بالفعل من جانب الخادم، وبحسب GitLab لم يكن مطلوبًا أي شيء.

بالنسبة لمشغّل مستضاف ذاتيًا، يكون القرار أضيق وأقل راحة من دورة ترقيع عادية. لا يوجد حل بديل لبوابة لا يمكن نقلها فورًا. ولا توجد طريقة مُصدَرة لتحديد ما إذا كان المضيف قد اختُرِق مسبقًا، ما يعني أن الخيار الوحيد بأثر رجعي هو الخيار العادي: التعامل مع الحاوية كنظام لم تُثبَت سلامته، والبحث عن علامات تنفيذ خارج سلوكها الطبيعي. وبالنسبة للبوابات على 18.x أو 19.1، لا تسمّي الاستشارية أي إصدار مستهدف على الإطلاق — وهو سهو يورده The Hacker News ولا يعالجه إشعار GitLab.

تصنيف الأرشيف نفسه أضيق عمدًا من تصنيف المورّد. فهو يسجّل هذا المدخل باعتباره ثغرة أمنية، بدرجة ثقة A مع اتفاق المصادر وعدم التنازع عليه، ودون تسجيل أي ضرر حقيقي، ومع حقل خطورة قيمته "high" مقابل "critical" لدى GitLab وNVD. هذه إجابات عن أسئلة مختلفة: فالدرجة تصف ما قد تسمح به العلة، بينما يصف تقييم الأرشيف ما يُعرف أنه حدث. وفي السجل العام، لم يحدث شيء — لا استغلال، ولا ضحايا، ولا تقرير حادث. وتكمن قيمة المدخل في أنه يوثّق، برقم CVE ونسخة مُصلحة، بالضبط كيف تحوّل قالب توجيه إلى سطر أوامر في البرمجيات الوسيطة التي تعتمد عليها ميزات الذكاء الاصطناعي المؤسسية.