طلب POST واحد غير مُصادَق عليه إلى واجهة إدارة Bifrost أدى إلى تشغيل أمر بصفة مستخدم البوابة

في 14 سبتمبر 2026، نشرت JFrog Security Research CVE-2026-90898، وهو عيب تنفيذ أوامر في Bifrost — بوابة الذكاء الاصطناعي مفتوحة المصدر التي تديرها Maxim — وصنّفته بـ9.8 من 10. كان الهجوم طلب HTTP واحدًا. طلب POST /api/mcp/client غير الموثّق يسجّل عميل MCP من نوع stdio، يقرأه Bifrost على أنه اسم برنامج مع قائمة وسائط ويشغّله فورًا، قبل أي مصافحة MCP، بصفة المستخدم الذي يشغّل البوابة؛ وعلى الصورة الرسمية يكون ذلك المستخدم appuser. البوابة هي أيضًا المكان الذي توجد فيه مفاتيح المزوّد والمفاتيح الافتراضية الخاصة بالمشغّل، لذا فإن أي عملية تعمل هناك تصل إلى بيانات الاعتماد. ما جعل الطلب مجهولًا هو إعداد افتراضي مضمّن: governance.auth_config.is_enabled يساوي false، وبعبارة JFrog، "إيقاف المصادقة يعني أن كل مستدعٍ مسؤول محلي." لا يذكر أي مصدر مُستشهد به أن العيب قد استُغل. توجد مصادر السجل نفسه ودرجة الخطورة وتقييم الثقة في أرشيف حوادث الذكاء الاصطناعي، إلى جانب ثغرات بوابات الذكاء الاصطناعي وMCP الأخرى الموثّقة خلال العام الماضي.

تُعدّ Bifrost خدمة واحدة تقع بين التطبيق ونماذج اللغة التي يستدعيها. ويصفها مستودعها بأنها بوابة مفتوحة المصدر مرخّصة بموجب Apache-2.0 «توحّد الوصول إلى أكثر من 23 مزوّدًا ... عبر واجهة API واحدة متوافقة مع OpenAI»، مع تضمين وكيل MCP، والمفاتيح الافتراضية، والميزانيات، وموازنة الأحمال لكل مزوّد ضمن ميزاتها، وقد حملت نحو 9,150 نجمة على GitHub في 28 أكتوبر 2026. وهذا المزيج هو السبب الكامل وراء استحقاق وجود شل على هذا المضيف تحديدًا درجةً حرجة: فالعملية التي توجّه الطلبات هي أيضًا العملية التي تحتفظ ببيانات الاعتماد لكل خدمة أعلى تقوم بالتوجيه إليها. وقد ذكرت Hacker News، عند إبلاغها عن العيب في 22 سبتمبر، النتيجة بوضوح — لأن البوابة تخزّن مفاتيح API لكل مزوّد متصل، فإن تنفيذ أوامر على عملية البوابة يمنح المهاجم وصولًا إلى تلك البيانات.

كان الهجوم بأكمله عبارة عن POST واحد

تحذير JFrog، المنشور تحت المرجع JFSA-2026-001686326، يصف نقطة نهاية موجودة لتمكين المسؤول من إضافة خادم MCP. إن عميل stdio في مواصفات MCP ليس عنوان URL؛ بل هو أمر ومعطياته، ومن المتوقع أن يقوم البرنامج المضيف بتشغيله. يقبل Bifrost ذلك التكوين عبر واجهة إدارة API ويبدأ تشغيل البرنامج بمجرد إضافة العميل. لا تفاوض على القدرات، ولا تحقق من هوية الخادم، ولا يلزم نجاح أي مصافحة أولاً — فالتحذير صريح في أن المصافحة ليست ما يبدأ العملية.

يتضمّن إثبات المفهوم الوارد في التنبيه جسم JSON قصير يُرسَل إلى بوابة مع ترك المصادقة على إعدادها الافتراضي. وهو يسجّل عميلًا أمره هو ‎/bin/sh‎ ووسائطه تكتب ملف علامة، ثم يقرأ ملف العلامة هذا مرة أخرى. ويضيف JFrog تفصيلًا تشغيليًا مهمًا أثناء الاستجابة للحوادث: قد ينتهي طلب HTTP بمهلة بينما ينتظر Bifrost مصافحة لا تأتي أبدًا، وانتهاء المهلة في السجلات لا يعني أن الأمر لم يبدأ. فالعملية تكون قيد التشغيل بالفعل بحلول ذلك الوقت.

يصنّف سجل CVE، المُسنَد من JFrog بوصفها هيئة ترقيم CVE، العيب ضمنCWE-306، انعدام المصادقة لوظيفة حرجة، وCWE-284، وضعف التحكم في الوصول، ويسمّي الملفين اللذين يحتويان على المعالج والبرمجية الوسيطة الخاصة به: transports/bifrost-http/handlers/mcp.go وtransports/bifrost-http/handlers/middlewares.go. الوحدة النمطية المتأثرة هي github.com/maximhq/bifrost/transports، على Linux وmacOS، في كل إصدار أقل من 2.1.0.

الإعداد الافتراضي الذي جعل الطلب مجهولاً

لن يكون أي من ذلك قابلاً للاستغلال دون شرط ثانٍ، والشرط الثاني هو الإعداد الافتراضي للمنتج نفسه. فالوسيطة الخاصة بمصادقة الإدارة في Bifrost مشروطة بـ governance.auth_config.is_enabled، الذي يأتي بقيمة false. وعند إيقافها، تعامل الوسيطة كل مستدعٍ كمسؤول محلي — وملخص التنبيه نفسه هو أن إيقاف المصادقة يعني أن كل مستدعٍ مسؤول محلي — لذا فإن الفحص الذي كان سيمنع الطلب لم يكن في المسار أصلاً.

الإصلاح، طلب السحب #6757، دُمج في المشروع في 2 سبتمبر 2026، أي قبل اثني عشر يومًا من نشر CVE وقبل ستة أيام من الإصدار الذي يحمله. ويصفه وصفه بصراحة غير معتادة لطبيعة المشكلة: إذ يغلق طلب السحب بدائيتين للوصول غير المصادق في واجهة API نفسها للتسجيل، لا بدائية واحدة. الأولى هي عميل stdio. والثانية هي عميل MCP من نوع http أو sse موجّه إلى عنوان loopback أو عنوان شبكة خاصة، وهو ما يسميه الطلب بدائية SSRF ضد الخدمات الداخلية، «بما في ذلك نقطة نهاية البيانات الوصفية السحابية 169.254.169.254». ويُرفض كلاهما الآن باستجابة HTTP 403 عندما يصل الطلب إلى المعالج دون تحقق حقيقي من بيانات الاعتماد. ويحتفظ المسؤولون المصادقون بكلتا القدرتين، ولا يزال بإمكان المشغلين تهيئة عملاء stdio عبر config.json.

لا تظهر البدائية الثانية في نص CVE. بل تظهر في التصحيح، وهي السبب في أن الإصلاح جاء كبوابة تحقق بدلًا من إزالة: فالميزة لم تكن هي الخلل يومًا، بل كان التعامل مع مستدعٍ غير مُصادَق عليه باعتباره مسؤولًا.

أين كانت واجهة برمجة تطبيقات الإدارة تستمع فعليًا

إمكانية الوصول هي الجزء من السجل الذي تصفه المصادر على نحو أكثر اتساقًا، وتقيسه بأقل قدر. تحدّد إرشادات JFrog القيمة الافتراضية للثنائي القياسي بأنها localhost:8080، ما يحصر المهاجم في المضيف نفسه. وتنص إرشادات الفريق نفسه الخاصة بالثغرة المرافقة على أن صورة Docker الرسمية تربط 0.0.0.0 بدلًا من ذلك، ويكرر The Hacker News ذلك: تجعل الصورة واجهة إدارة API قابلة للوصول من خارج الحاوية إذا نُشر المنفذ. ويشغّل البدء السريع في README الخاص بـ Bifrost الأمر "docker run -p 8080:8080 maximhq/bifrost"، وينشر خيار -p في Docker منفذ حاوية على كل واجهة مضيف ما لم يُحدَّد عنوان. ويسجّل إرشاد GitHub الخاص بالثغرة أنه جرى التحقق من المسار المُبلَّغ عنه مقابل صورة maximhq/bifrost:latest المنشورة، حيث أطلق طلب غير مُصادَق عليه /bin/sh وكتب علامة بصفة appuser.

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

نقطة نهاية واحدة، عيبان، سبب جذري واحد

قبل ثمانية أيام من تنبيه MCP، في 6 سبتمبر 2026، نشر فريق البحث نفسه CVE-2026-86242، وهو مسار ثانٍ غير مُصادَق عليه إلى العملية نفسها. اكتشفه Or Peles وحصل على تقييم 8.1، ويستغل POST /api/plugins: يقبل Bifrost ملحقاً مخصصاً مُفعّلاً يكون مساره عنوان URL من نوع HTTP، فيتعامل محمّل الكائنات المشتركة مع المسار الذي يبدأ بـ http باعتباره تنزيلاً، ويكتب المحتوى في ملف .so مؤقت ويسلّم ذلك الملف إلى plugin.Open في Go. إذا نجح التحميل، تُشغَّل دالة Init اختيارية فوراً باستخدام إعدادات المهاجم، بصفة مستخدم البوابة.

يحدد نمط البناء ما يحصل عليه المهاجم. في عمليات البناء المرتبطة ديناميكيًا التي يوثّقها المشروع لإضافات Go المخصصة، يُتوقع أن ينجح التحميل، وهو ما يصفه التنبيه بأنه تنفيذ شيفرة عن بُعد دون مصادقة. أما في صورة Docker المنشورة والمرتبطة ارتباطًا ثابتًا، فيفشل plugin.Open برسالة "Dynamic loading not supported"، لذا يتحول الطلب نفسه إلى تزوير طلبات من جهة الخادم. ويجب أن تتطابق أي إضافة قابلة للتحميل أيضًا مع إصدار Go ونظام التشغيل والبنية وطريقة الربط لدى المضيف، وهذا قيد حقيقي وليس إجراءً شكليًا. الإصلاح هو transports/v2.0.0، عبر طلب السحب #5763، والنطاق المتأثر هو كل ما يسبقه.

الفخّ هو ترتيب الإصدارات. يُصلح v2.0.0 مسار plugin ولا يُصلح مسار MCP — وتقول The Hacker News ذلك صراحةً، كما تؤكد استشارة MCP من JFrog أن v2.0.0 لا يزال يسمح بتسجيل stdio دون مصادقة. وكان المشغّل الذي طبّق التصحيح سريعًا بعد استشارة 6 سبتمبر، من هذه النقطة وحدها، لا يزال معرّضًا حتى صدور transports/v2.1.0 في 8 سبتمبر. وتختزل العلّتان إلى الجملة نفسها في كلتا الاستشارتين وفي طلب السحب الخاص بالمورّد نفسه: تعطيل المصادقة هو الإعداد الافتراضي.

ما تثبته المصادر، وما لا تثبته

الآلية ونطاق الإصدارات والإصلاح والإسناد متفق عليها في النشرة الأمنية، وسجل CVE الذي خصصه JFrog، وطلب السحب وملاحظات الإصدار الخاصين بالمشروع، وThe Hacker News. أما الخلاف المتبقي فيدور حول درجة الخطورة، وهو خلاف حقيقي.

الدرجة 9.8 هي درجة JFrog بصفتها CNA المانحة، وهي الدرجة التي تحملها NVD — إذ يسرد سجل NVD العنوان reefs@jfrog.com مصدرًا للمقياس، واعتبارًا من 28 أكتوبر 2026، لا يزال يُظهر المدخل بحالة "Awaiting Analysis"، أي أن NVD قد نشرت متجه الجهة المانحة بدلًا من تحليلها الخاص له. ويشير تقييم SSVC الصادر عن منسّق CISA والملحق بالسجل نفسه، والمؤرّخ في 14 سبتمبر 2026، إلى أن الاستغلال "none"، والقابلية للأتمتة "yes"، والأثر التقني "total". وقد وضع نموذج EPSS التابع لـ FIRST احتمال الاستغلال خلال الـ30 يومًا القادمة عند 2.3 بالمئة في 27 أكتوبر 2026، ضمن المئين 83 عبر جميع CVEs التي جرى تقييمها، ولا يظهر هذا CVE ولا CVE-2026-86242 في كتالوج CISA Known Exploited Vulnerabilities المؤرّخ في 27 أكتوبر 2026.

في المقابل، يعترض مكسيم على التقييم. وفي بيان إلى The Hacker News، قال أكشاي ديو، كبير مسؤولي التكنولوجيا والشريك المؤسس في الشركة، إن الخطر العملي أقل مما توحي به الدرجة الحرجة، لأن الاستغلال يتطلب أن تكون واجهة الإدارة قابلة للوصول من شبكة غير موثوقة وأن يكون المشغّل قد ترك المصادقة غير مضبوطة؛ وقال إن النشر الافتراضي والموثّق يضع البوابة داخل شبكة خاصة. وتذكر The Hacker News أن مكسيم يعتبر العيب منخفض الخطورة ويعمل مع JFrog، التي أسندت CVE، على مراجعة التقييم. ويظهر ذلك البيان في ذلك المنفذ الإعلامي وحده؛ ولم يُعثر على منشور ثانٍ يقتبس موقف مكسيم، ولم يكن قد نُشر أي تعديل حتى 28 أكتوبر 2026 — فقد حُدّث سجل CVE آخر مرة في 14 سبتمبر ومدخل NVD في 18 سبتمبر، وكلاهما لا يزال عند 9.8.

ثمة فجوتان إضافيتان جديرتان بالتسمية بدلاً من التلميع عليهما. فلا تزال النشرات الاستشارية الأمنية للمشروع على GitHub، المنشورة في 23 سبتمبر 2026 والتي تَنسب الإبلاغ إلى باحث من JFrog، تحمل 9.8 لعلّة MCP و8.1 لعلّة الإضافة، من دون أي أثر للمراجعة التي وصفها Maxim. كما أن النطاقات المتأثرة في تلك النشرات مكتوبة مقابل إصدارات وحدات Go — أقل من 1.5.27 وأقل من 1.6.3 — بدلاً من وسوم إصدار transports التي تستخدمها نشرات JFrog الاستشارية، لذا على المشغّل الذي يطابق وثيقة بأخرى أن يوفّق بين نظامَي ترقيم قبل أن يقرر ما إذا كانت نسخة البناء متأثرة.

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

يسير التسلسل الزمني إلى الوراء انطلاقًا من الإفصاح، وهو الجزء الأقل بداهةً في السجل. تم دمج طلب السحب #6757 في 2 سبتمبر 2026. ونُشر transports/v2.1.0، وهو الإصدار الذي تسمّيه الاستشارة الأمنية أول إصدار يحتوي على الإصلاح، في 8 سبتمبر — أي قبل ستة أيام من نشر CVE-2026-90898 في 14 سبتمبر. وبالطريقة نفسها، سبق إصلاح المكوّن الإضافي في المشروع استشارته الأمنية الخاصة: فقد صدر transports/v2.0.0 في 26 أغسطس، أي قبل أحد عشر يومًا من CVE الصادر في 6 سبتمبر. وكان لدى المشغّلين الذين يتابعون الإصدارات بدلًا من الموجزات التصحيحاتُ قبل أن تصلهم التحذيرات.

ما تحققه الترقية محدود ومحدد. في الإصدار 2.1.0 وما بعده، يُرجع تسجيل stdio غير المصادق عليه رمز 403 ولا يبدأ الأمر؛ ويحتفظ المسؤولون المصادقون بهذه القدرة، ولا يزال تزويد config.json يعمل. يتمثل الحل المؤقت الذي يوصي به التنبيه لكل من لا يستطيع الانتقال في تعيين governance.auth_config.is_enabled إلى true، واستخدام بيانات اعتماد قوية للمسؤول، وإبقاء مستمع الإدارة بعيدًا عن الشبكات غير الموثوقة. ليست تعليمات JFrog للنسخ التي عملت مكشوفة مع تعطيل المصادقة هي التحقيق والأمل، بل التعامل معها على أنها مخترقة، وتدوير المفاتيح الظاهرية وبيانات اعتماد المزوّد.

حساب الإصدارات هو الجزء الأكثر عرضة لسوء الفهم. لا يصلح v2.0.0 هذا العيب. كما لا تحتوي سلسلة 1.6.x حتى 1.6.11 على الإصلاح، وأحدث وسم في سلسلة 1.6 للمشروع هو transports/v1.6.11، نُشر في 14 أغسطس 2026، ولا توجد سلسلة 1.7 في المستودع حتى 28 أكتوبر 2026 — لذا لا يوجد إصدار مُرقّع داخل تلك السلسلة، وعلى مشغّل 1.6.x الانتقال إلى 2.1.0 أو أحدث بدلًا من انتظار نقل الإصلاح إلى إصدار أقدم. وخط الإصدار الحالي تجاوز تلك النقطة بكثير: نُشر transports/v2.3.2 في 20 أكتوبر 2026.

حدث أمران بعد النشر يمكن للمدافع الاستفادة منهما. فقد نُشرت التنبيهات الأمنية لمشروع GitHub — GHSA-86gf-xh3g-rvxq الخاصة بثغرة MCP ذات الخطورة الحرجة وGHSA-2qp8-4xgm-fw6g الخاصة بثغرة الإضافة ذات الخطورة العالية — في 23 سبتمبر 2026، مما منح خلاصات الاعتماديات والتنبيهات معرفًا ثانيًا للمطابقة. وفي 13 أكتوبر 2026، دُمج قالب كشف خاص بـ CVE-2026-90898 في مستودع nuclei-templates العام، ما يعني أن فحص محاولة تسجيل دون مصادقة أصبح شيئًا يمكن لخط أنابيب فحص تشغيله بدلًا من أن يضطر كل فريق إلى كتابته.

ما يبقى معلقًا هو درجة الخطورة، وسيُحسم أو لن يُحسم من قبل المنظمتين اللتين ما زالتا تتحدثان بشأنه. موقف Maxim، كما نُقل، هو أن درجة 9.8 تبالغ في تقدير ثغرة لا تصبح ذات أهمية إلا إذا توفر مستمع مكشوف وإعداد افتراضي غير مضبوط — وهو ادعاء قابل للاختبار من حيث المبدأ وغير مختبر علنًا، لأن أحدًا لم ينشر عدد عمليات النشر التي استوفت هذين الشرطين. أما موقف JFrog فهو الدرجة التي أسندها بصفته CNA، ولا تزال قائمة في سجل CVE وفي NVD. وإلى أن تنشر إحداهما مراجعة، فإن القراءة التشغيلية تظل واحدة في الحالتين: الثغرة حقيقية وقد جرى التحقق منها من البداية إلى النهاية على صورة الحاوية المنشورة، والإصلاح صدر قبل التحذير، وسلسلة 1.6 لا تحتوي على أي إصلاح على الإطلاق، وأي نسخة كانت تعمل مع تعطيل المصادقة على مستمع يمكن الوصول إليه ينبغي التعامل معها كحادث بيانات اعتماد لا كتصحيح ينبغي جدولته.