آسیبپذیری در Starlette امکان دور زدن احراز هویت مبتنی بر مسیر در FastAPI را فراهم میکند

محققان امنیتی در X41 D-Sec که روی یک ممیزی مالی توسط OSTIF روی فریمورک استنتاج vLLM کار میکردند، یک آسیبپذیری بحرانی دور زدن احراز هویت در Starlette کشف کردند؛ همان فریمورک ASGI پایتون که زیربنای FastAPI و اکوسیستم گستردهای از زیرساختهای agent هوش مصنوعی است. این آسیبپذیری با شناسه CVE-2026-48710 و نام BadHost به مهاجم اجازه میدهد هدر HTTP Host را دستکاری کند تا Starlette مسیر URL متفاوتی از آنچه وبسرور واقعاً مسیریابی کرده گزارش دهد و هر middlewareای را که برای تصمیمگیریهای کنترل دسترسی از request.url.path استفاده میکند، دور بزند. رفع این مشکل در Starlette 1.0.1 ارائه شده است.
دامنه تأثیر گسترده است. Starlette بیش از ۴۰۰٬۰۰۰ وابسته در GitHub و بیش از ۳۲۵ میلیون دانلود هفتگی در PyPI دارد. برنامههای تحت تأثیر شامل هر چیزی است که روی FastAPI با middleware احراز هویت مبتنی بر مسیر ساخته شده است، به همراه مجموعه خاصی از ابزارهای زیرساخت هوش مصنوعی: vLLM، LiteLLM، سرورهای Model Context Protocol (MCP)، FastMCP، ADK-Python گوگل، Ray Serve و BentoML همگی در صورت وجود middleware احراز هویت سفارشی آسیبپذیر هستند.
نحوه عملکرد حمله
درخواستهای HTTP شامل یک هدر Host هستند که دامنه مقصد را مشخص میکند. Starlette شیء request.url خود را با الحاق هدر خام Host به مسیر درخواست میسازد و سپس رشته ترکیبی را دوباره به یک شیء URL تجزیه میکند. مشکل این است که Starlette قبل از استفاده از این ساختار، تأیید نکرده است که هدر Host با دستور زبان RFC 9112 مطابقت دارد. یک مهاجم میتواند کاراکترهای جداکننده مسیر — /، ? یا # — را به هدر Host تزریق کند که آنچه تجزیهگر بهعنوان مسیر، query و fragment میبیند هنگام تجزیه مجدد URL تغییر میدهد.
نتیجه یک نمای دوتایی است: سرور ASGI درخواست را به مسیر واقعی هدایت میکند (مثلاً /admin)، اما request.url.path — که middleware احراز هویت میخواند — مسیر تحت کنترل مهاجم را گزارش میدهد (/health یا هر مسیر بیخطری که middleware مجاز میداند). مشاوره X41 شامل یک proof-of-concept ساده است:
curl -H 'Host: foo?' localhost:8000/admin
در یک سرور آسیبپذیر با احراز هویت مبتنی بر مسیر، این دستور از endpoint محافظتشده /admin پاسخ 200 OK را برمیگرداند نه 403 Forbidden.
دلیل شناسایی نشدن این آسیبپذیری برای مدت طولانی این است که از تعامل سه لایه ناشی میشود که هرکدام بهتنهایی منطقی به نظر میرسند: سرورهای ASGI هدر خام Host را بدون اعتبارسنجی عبور میدهند؛ Starlette برای ساخت URL به آن اعتماد میکند؛ و توسعهدهندگان middleware فرض میکنند request.url.path یک مقدار امن و معتبر از سمت سرور برای کنترل دسترسی است. هیچ لایهای بهتنهایی خراب نیست.
چه کسانی تحت تأثیر هستند
این آسیبپذیری بیشتر برای برنامههایی اهمیت دارد که دسترسی به endpointهای محافظتشده را با middlewareای که مسیر درخواست را بررسی میکند، کنترل میکنند. این الگویی رایج در برنامههای FastAPI است که یک پیشوند مسیر (مانند /admin, /internal یا /v1/private) مجوز دسترسی را تعیین میکند. برنامههایی که از دکوراتورهای داخلی Depends() یا Security() FastAPI در سطح مسیر استفاده میکنند، معمولاً تحت تأثیر نیستند، زیرا این مکانیسمها مجوز را در زمان حل مسیر بررسی میکنند نه از طریق بازرسی مسیر در middleware.
تأثیر بر زیرساخت هوش مصنوعی جدیترین نگرانی است. سرورهای MCP — که پروتکل Model Context Protocol را برای اتصال agentهای هوش مصنوعی به ابزارها و منابع داده پیادهسازی میکنند — بهویژه در معرض خطر هستند، زیرا مشخصات MCP نیازمند endpointهای کشف OAuth بدون احراز هویت است و به مهاجمان یک مسیر دور زدن قابل اعتماد و شناختهشده میدهد بدون اینکه نیاز به حدس مسیرهای محافظتنشده داشته باشند. vLLM و LiteLLM که بهطور گسترده برای سرویسدهی و پروکسی کردن مدلهای زبانی بزرگ در محیط تولید استفاده میشوند، زمانی که پشت middleware احراز هویت سفارشی مبتنی بر Starlette قرار میگیرند تحت تأثیر قرار میگیرند. ADK-Python گوگل، SDK پایتون برای ساخت agentهای هوش مصنوعی با مدلهای گوگل نیز در لیست تحت تأثیر قرار دارد.
رفع مشکل
راهحل اصلی ارتقا به Starlette 1.0.1 است که هدرهای Host حاوی کاراکترهای نامعتبر را بهجای استفاده از آنها برای ساخت URL رد میکند. برای برنامههایی که نمیتوانند فوراً ارتقا دهند، اقدام کاهشی جایگزینی هرگونه استفاده از request.url.path در middleware احراز هویت یا مجوزدهی با scope["path"] است — مسیر scope ASGI که مستقیماً از خط درخواست HTTP میآید و تحت تأثیر هدر Host نیست. توصیه بلندمدت این است که بهکلی از احراز هویت مبتنی بر مسیر در middleware خودداری شود و به جای آن از مکانیسمهای Depends() و Security() در سطح مسیر FastAPI استفاده شود.
تیم تحقیقاتی همزمان با افشا، ابزارهای شناسایی را نیز منتشر کردند: قوانین Semgrep، پرسوجوهای CodeQL برای تحلیل استاتیک و یک اسکنر رایگان در badhost.org که میتواند endpointها را مستقیماً آزمایش کند. اسکنر از سه حالت پشتیبانی میکند — مخصوص MCP، کشف خودکار زیرساخت هوش مصنوعی و تست مسیر سفارشی — تا تیمها بتوانند بدون نیاز به خواندن کامل مشاوره، میزان مواجهه را ارزیابی کنند.
CVE-2026-48710 در ۲۷ ژانویه ۲۰۲۶ کشف شد و برای افشای عمومی در ۲۱–۲۲ می ۲۰۲۶ هماهنگ شد، پس از انتشار پچ 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