ثغرة Starlette تتيح للمهاجمين تجاوز المصادقة على أي تطبيق FastAPI يعتمد على المصادقة القائمة على المسار

اكتشف باحثون في X41 D-Sec، أثناء عملهم على تدقيق مدعوم من OSTIF لإطار استدلال vLLM، ثغرة خطيرة في تجاوز المصادقة في Starlette – إطار Python ASGI الذي يقوم عليه FastAPI ونظام بيئي واسع من البنية التحتية لوكلاء AI. تُصنف الثغرة باسم CVE-2026-48710 وتسمى BadHost، وتسمح للمهاجم بتلاعب رأس HTTP Host header لجعل Starlette تبلغ عن مسار URL مختلف عن المسار الذي وجهه خادم الويب فعليًا – متجاوزةً أي وسيط (middleware) يستخدم request.url.path لاتخاذ قرارات التحكم في الوصول. الإصلاح متاح في Starlette 1.0.1.
نطاق التأثير واسع. لدى Starlette أكثر من 400 ألف معتمد على GitHub وأكثر من 325 مليون تحميل أسبوعي على PyPI. التطبيقات المتأثرة تشمل أي شيء مبني على FastAPI مع وسيط مصادقة يعتمد على المسار، بالإضافة إلى مجموعة محددة من أدوات البنية التحتية للذكاء الاصطناعي: vLLM وLiteLLM وخوادم Model Context Protocol (MCP) وFastMCP وGoogle ADK-Python وRay Serve وBentoML – جميعها معرضة للخطر عند وجود وسيط مصادقة مخصص.
آلية الهجوم
تحتوي طلبات HTTP على رأس Host header يُعرّف النطاق المستهدف. تقوم Starlette ببناء كائن request.url عن طريق دمج رأس Host الخام مع مسار الطلب، ثم إعادة تحليل السلسلة المدمجة إلى كائن URL. المشكلة: لم تتحقق Starlette من أن رأس Host يتوافق مع قواعد RFC 9112 قبل استخدامه في هذا البناء. يستطيع المهاجم إدخال أحرف فاصلة للمسار – / و ? و # – في رأس Host، مما يغير ما يراه المحلل كمسار واستعلام وجزء (fragment) عند إعادة تحليل عنوان URL المجمع.
النتيجة هي انقسام في الرؤية: يقوم خادم ASGI بتوجيه الطلب إلى المسار الحقيقي (مثلاً /admin)، بينما يبلغ request.url.path – الذي يقرأه وسيط المصادقة – عن مسار يتحكم به المهاجم بدلاً من ذلك (مثلاً /health، أو أي مسار آخر غير ضار يسمح به الوسيط). يتضمن تقرير X41 إثبات المفهوم بهذه البساطة:
curl -H 'Host: foo?' localhost:8000/admin
على خادم ضعيف مع مصادقة قائمة على المسار، يعيد هذا الأمر استجابة «200 OK» من نقطة النهاية المحمية /admin بدلاً من «403 Forbidden».
سبب عدم اكتشاف الثغرة لفترة طويلة هو أنها تنشأ من تفاعل ثلاث طبقات تبدو كل منها معقولة بشكل منفرد: تمرر خوادم ASGI رأس Host الخام دون تحقق؛ وتثق Starlette به لبناء عنوان URL؛ ويفترض مطورو الوسائط أن request.url.path قيمة آمنة وموثوقة من الخادم للتحكم في الوصول. لا توجد طبقة واحدة معطوبة بمفردها.
الفئات المتأثرة
تكون الثغرة أكثر أهمية للتطبيقات التي تتحكم في الوصول إلى نقاط النهاية المحمية باستخدام وسيط يفحص مسار الطلب. هذا نمط شائع في تطبيقات FastAPI حيث تحدد بادئة المسار (مثل /admin أو /internal أو /v1/private) مستوى التفويض. التطبيقات التي تستخدم أدوات FastAPI المضمنة Depends() أو Security() على مستوى المسار الفردي لا تتأثر عادةً، لأن هذه الآليات تتحقق من التفويض وقت تحليل المسار وليس عبر فحص المسار في الوسيط.
تأثير البنية التحتية للذكاء الاصطناعي هو الأكثر إلحاحًا. خوادم MCP – التي تطبق Model Context Protocol لربط وكلاء AI بالأدوات ومصادر البيانات – معرضة بشكل خاص لأن مواصفات MCP تفرض نقاط نهاية اكتشاف OAuth غير مصادق عليها، مما يمنح المهاجمين مسارًا معروفًا وموثوقًا للاختراق دون الحاجة إلى تخمين المسارات غير المحمية. vLLM وLiteLLM، المستخدمتان على نطاق واسع لخدمة وتمثيل نماذج اللغات الكبيرة في الإنتاج، تتأثران عندما تكونان خلف وسيط مصادقة مخصص يعتمد على Starlette. Google ADK-Python، حزمة Python SDK لبناء وكلاء AI باستخدام نماذج Google، هي أيضًا ضمن القائمة المتأثرة.
الإصلاح
الإصلاح الأساسي هو الترقية إلى Starlette 1.0.1، والذي يرفض رؤوس Host التي تحتوي على أحرف غير صالحة بدلاً من استخدامها في بناء URL. بالنسبة للتطبيقات التي لا يمكنها الترقية فورًا، يتمثل التخفيف في استبدال أي استخدام لـ request.url.path في وسيط المصادقة أو التفويض بـ scope["path"] – مسار نطاق ASGI، والذي يأتي مباشرةً من سطر طلب HTTP ولا يتأثر برأس Host. التوصية طويلة المدى هي تجنب المصادقة القائمة على المسار في الوسائط تمامًا لصالح آليات FastAPI على مستوى المسار مثل Depends() وSecurity().
أطلق فريق البحث أدوات كشف بالتزامن مع الإفصاح: قواعد Semgrep، واستعلامات CodeQL للتحليل الثابت، وماسح ضوئي مجاني على badhost.org يمكنه اختبار نقاط النهاية مباشرةً. يدعم الماسح ثلاثة أوضاع – خاص بـ MCP، واكتشاف تلقائي للبنية التحتية للذكاء الاصطناعي، واختبار مسار مخصص – حتى تستطيع الفرق تقييم التعرض دون قراءة التقرير بالكامل.
تم اكتشاف CVE-2026-48710 في 27 يناير 2026 وتم التنسيق للإفصاح العام في 21–22 مايو 2026، بعد إصدار تحديث Starlette 1.0.1. التفاصيل التقنية الكاملة موجودة في تقرير X41 على x41-dsec.de.
Originally reported by OSTIF / X41 D-Sec. Read the original article for additional details.
View original source