ثغرة 'BadHost': حرف واحد في ترويسة HTTP يتجاوز كل تأمين المسارات في ملايين وكلاء الذكاء الاصطناعي

آلية عمل ثغرة "BadHost" التقنية

جوهر المشكلة يكمن في خطأ منطقي داخل Starlette أثناء إعادة بناء عنوان URL للطلب. عندما يصلك طلب HTTP، يقوم الموجّه (Router) بتوجيه الطلب بناءً على المسار الخام الموجود في سطر الطلب. لكن لاحقًا، عندما يتحقق تطبيقك من صلاحية المستخدم، فإنه يسأل الكائن request.url. هنا مكمن الخطر: يقوم Starlette بإعادة بناء هذا العنوان عبر دمج ترويسة Host القادمة من المهاجم مع مسار الطلب، دون أدنى تدقيق .

يمكن للمهاجم استغلال ذلك بإرسال طلب إلى مسار محمي مثل /admin/secure لكن مع ترويسة Host مسمومة على النحو التالي:

النتيجة مذهلة: الموجّه يُرسل الطلب بشكل صحيح إلى معالج المسار السري /admin/secure. ولكن حين يحين وقت فحص التفويض، يقرأ الوسيط الأمني (Authorization Middleware) المسار من request.url.path فيجد أنه يشير إلى /health! لو كان هذا المسار مدرجًا في قائمة بيضاء كفحص صحي عام، فإن المخترق يعبر دون أي كلمة مرور أو رمز دخول .

فريق X41 D-Sec لخص الثغرة بعبارة بليغة: "ببساطة، إدراج حرف واحد في ترويسة HTTP Host يكفي لخداع الخادم" .

تأثير واسع النطاق في بيئات الذكاء الاصطناعي

هذه الثغرة ليست مجرد خطأ برمجي في مكتبة عادية. Starlette هي المحرك الخفي الذي يستخدمه جل مطوري بايثون، حيث يُحمل ما يقارب 325 مليون مرة أسبوعيًا. جميع المشاريع التي تعتمد على إصدارات Starlette الأقدم من 1.0.1 متأثرة بشكل مباشر .

أبرز الأنظمة المهددة تشمل:

• FastAPI: أشهر إطار عمل حديث لبناء واجهات API الخاصة بنماذج الذكاء الاصطناعي .
• vLLM: محرك استدلال عالي الأداء لنماذج اللغة الكبيرة، وهو المستهدف الأساسي بالتدقيق الأمني الذي اكتشف الثغرة .
• LiteLLM: طبقة وسيطة تدير مفاتيح API لمزودي نماذج متعددين، اختراقها يعني تسريب مفاتيح الوصول .
• خوادم MCP: الطبقة المسؤولة عن ربط وكلاء AI بالأدوات الخارجية، وفيها تُخزن بيانات حساسة مثل رموز الوصول وسياقات التنفيذ .

الجدل حول درجة الخطورة: لماذا "متوسط" تقييم مُضلل؟

أثار التقييم الرسمي لهذه الثغرة جدلاً واسعًا في أوساط الأمن السيبراني:

• التقييم الرسمي CVSS v3.1: 6.5 درجة (متوسط) – يعتبر التأثير على السرية والسلامة "منخفضًا" ولا يرى اختراقًا لحدود النطاق الأمني .
• تقييم X41 D-Sec باستخدام CVSS v4.0: 7.0 درجة (عالي) – يصنف النطاق على أنه "متغير" مع تأثير تكميلي "عالي"، موضحًا أن الثغرة تسمح بتجاوز حدود الصلاحيات .
• تصنيف شركة Secwest للأبحاث: حرج (Critical) – صرحت الشركة بأن التقييم الرسمي "يُقلل ماديًا من الأثر الفعلي على الأنظمة" .

ثلاثة عوامل تجعل تقييم 6.5 خطيرًا ومضللاً:

1. خرق لحدود الثقة الأمنية: نموذج CVSS v3.1 يفترض بقاء المخترق داخل نطاق واحد. لكن "BadHost" تسمح لمخترق خارجي وغير مصرح له بالوصول لنقاط نهاية داخلية محمية تتعامل مع نماذج وأدوات وبيانات حساسة. هذا قفزة أمنية حقيقية عالجها CVSS v4.0 بمقاييس التأثير التكميلي .
2. قيمة التأثير الحقيقية "عالية" وليست "منخفضة": الوصول للمسار لا يعني فقط رؤية بيانات محدودة، بل قد يمنح المخترق كامل البيانات خلفه: سجلات المحادثات، مفاتيح API السرية، أوراق اعتماد خوادم MCP، وحتى أوامر لوحة التحكم .
3. تأثير تصنيف "متوسط" على سرعة التصحيح: المنظمات تعطي أولوية فورية للثغرات "حرجة" و"عالية"، وتترك "المتوسطة" لجداول الصيانة الدورية. تصنيف ثغرة بهذه السهولة في الاستغلال والحجم الهائل بـ"متوسط" يبطئ التصحيح ويعرض الأنظمة لخطر أكبر .

الإصلاح: الترقية الفورية إلى Starlette 1.0.1

أصدر فريق Encode الإصدار Starlette 1.0.1 في 22 مايو 2026 وهو يوفر الإصلاح الشامل. التصحيح مُسجل في النشرة الأمنية على GitHub تحت اسم GHSA-86qp-5c8j-p5mr .

ماذا يفعل التصحيح تحديدًا؟

1. تدقيق ترويسة المضيف (Host): يتم التحقق من صحة الترويسة وفقًا للقواعد المحددة في معايير RFC 9112 و RFC 3986 قبل الشروع في استخدامها لبناء request.url .
2. آلية تراجع آمنة: عند اكتشاف ترويسة Host مشوهة، يتجاهلها Starlette ويعود لاستخدام scope["server"] (بيانات اتصال الخادم الحقيقية)، مما يضمن أن request.url.path تعكس دائمًا المسار الفعلي المطلوب .

خطة الاستجابة العاجلة للمؤسسات

الترقية هي خط الدفاع الأول ولكن الحماية الشاملة تتطلب إجراءات فورية متعددة:

1. التصحيح الفوري: في كل بيئة افتراضية وصورة حاوية ومسار نشر، نفذ:

   bash

   pip install --upgrade starlette

   وأعد تشغيل جميع الخدمات المتأثرة. هذا يشمل تثبيتات Starlette المباشرة وكذلك FastAPI وvLLM وLiteLLM وخوادم MCP .

2. تثبيت ومراجعة تبعيات المشروع: أطر العمل مثل FastAPI قد لا تفرض تلقائيًا الإصدار الأدنى من Starlette، بل تكتفي بنطاق واسع. يجب التصريح بشكل صريح بـ starlette>=1.0.1 في ملفات requirements.txt أو pyproject.toml أو poetry.lock. استخدم الأمر

   pip list | grep starlette

   لفحص جميع البيئات .

3. فحص كل مكون في حزمة AI: أي خدمة Python تقدم HTTP، مثل تطبيقات FastAPI المخصصة أو نقاط نهاية استدلال LLM أو وكلاء التنسيق أو الوكلاء المتوافقين مع OpenAI، قد تحوي إصدارًا ضعيفًا من Starlette. أجرِ تدقيقًا بنيويًا كاملاً .

4. تحصين الخوادم الوسيطة وجدران الحماية (WAF): اضبط إعدادات nginx، Envoy، HAProxy، Cloudflare، أو AWS ALB لرفض أو تطهير ترويسات Host المشوهة قبل أن تصل لتطبيق Python. هذا يوفر دفاعًا عميقًا يمنع الاستغلال حتى لو تأخر التصحيح الأساسي .

5. تعديل منطق التأمين: الخلل الجذري كان عدم التطابق بين مسار التوجيه وrequest.url.path. حيثما أمكن، غيّر أكواد التأمين الوسيطة لتعتمد على request.scope["path"] الآتي من سياق ASGI الخام وغير القابل للتسميم عبر ترويسة Host . ينصح فريق X41 D-Sec بالابتعاد عن التأمين المبنى على المسار أصلاً والتوجه نحو آليات تحقق ملازمة لنقاط النهاية .

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