BadHost: как CVE-2026-48710 в Starlette угрожает MCP и AI-агентам
BadHost в Starlette показывает, как обычная ошибка Host header превращается в риск для MCP-серверов, LLM proxy и OpenAI-compatible API.
По состоянию на 27 мая 2026 года BadHost / CVE-2026-48710 уже закрыт в Starlette 1.0.1, но сама история важнее обычного «обновитесь срочно». Уязвимость бьёт по месту, где Python-веб-стек встречается с инфраструктурой AI-агентов: MCP-серверами, LLM proxy, vLLM, LiteLLM, OpenAI-compatible API и внутренними панелями управления.
Суть неприятная: Starlette до 1.0.1 мог строить request.url из непроверенного HTTP Host header. Если приложение принимало решения безопасности по request.url.path, а не по реальному ASGI path, злоумышленник мог заставить middleware увидеть один путь, пока роутер выполнял другой. На практике это превращается в риск обхода path-based auth, а дальше всё зависит от того, что спрятано за «внутренним» endpoint: список моделей, управление ключами, запуск tools, загрузка файлов или кодовый eval.
Для читателей Toolarium это не отдельная байка про Starlette. Мы уже разбирали, как устроен MCP как стандарт интеграции ИИ с инструментами. BadHost показывает соседний слой риска: даже если протокол и модель настроены аккуратно, агентный контур всё равно наследует ошибки обычного HTTP-приложения.
Что случилось
22 мая 2026 года X41 D-Sec опубликовала advisory X41-2026-002 по Starlette. В нём подтверждены затронутые версии starlette >= 0.8.3, < 1.0.1 и исправленная версия 1.0.1. GitHub advisory GHSA-86qp-5c8j-p5mr даёт тот же практический вывод: affected versions <=1.0.0, patched version 1.0.1. Релиз Starlette 1.0.1 вышел 21 мая 2026 года и прямо указывает на изменение «Ignore malformed Host header when constructing request.url».
Механизм можно объяснить без инструкции по эксплуатации. HTTP-запрос содержит путь, по которому ASGI-сервер маршрутизирует запрос, и заголовок Host. В старых версиях Starlette значение Host попадало в реконструкцию полного URL без строгой проверки. Если в заголовке оказывались символы, которые меняют границы path, query или fragment, request.url.path мог отличаться от пути, который реально пришёл в сервер.
Роутер Starlette при этом продолжал отправлять запрос в настоящий endpoint. А middleware, которое смотрело на реконструированный request.url.path, могло решить, что запрос идёт в безопасный или публичный путь. Поэтому уязвимость опасна не для любого Starlette-приложения одинаково, а для тех случаев, где авторизация, allowlist, rate limit, audit или routing decisions завязаны на request.url или request.url.path.
Почему это касается MCP и AI-агентов
OSTIF в публикации отдельно перечисляет FastAPI, LiteLLM, vLLM, OpenAI shim proxies, MCP-серверы, agent harnesses, eval dashboards и model-management UI. Из этого не следует, что каждый такой сервис уже взломан. Смысл другой: многие AI-инструменты подняты на Python/ASGI, зависят от Starlette через FastAPI или соседние компоненты и часто держат рядом высокоценные endpoint.
У классического веб-приложения за закрытым путём может лежать админка. У агентной инфраструктуры там нередко находятся ключи, настройки моделей, вызовы tools, доступ к внутренним данным, управление runtime и прокси к моделям. Поэтому обычный auth bypass в таком контуре быстро становится риском для всего рабочего процесса.
В зоне особого внимания прямые ASGI-развёртывания без нормализующего reverse proxy перед ними. OSTIF отдельно пишет, что nginx, Apache httpd и Cloudflare по умолчанию отклоняют показанный класс некорректных Host header, но проверять нужно конкретную конфигурацию. Для HTTP/3-терминации и QUIC-фронтендов авторы советуют тестировать поведение отдельно.
С vLLM и OpenAI-compatible API ситуация похожая. В материале про то, как развернуть LLM на сервере с vLLM, мы отдельно говорили о боевом контуре вокруг inference-сервера. BadHost добавляет к этому простой критерий: endpoint управления моделями и ключами нельзя защищать только middleware, который смотрит на реконструированный URL.
Где риск реальный, а где начинается паника
Оценки серьёзности расходятся. GitHub advisory помечает проблему как Moderate и показывает CVSS 6.5/10. X41 ставит High. BadHost.org называет её critical, потому что смотрит на downstream-эффект для AI-инфраструктуры. В статье разумнее держать оба уровня в голове: дефект в библиотеке сам по себе условный, но последствия резко растут, если за обходом path-based auth стоит чувствительный endpoint.
| Факт | Что это значит для команды | Источник |
|---|---|---|
Starlette до 1.0.1 мог использовать некорректный Host при построении request.url. |
Нужно обновить Starlette и пересобрать контейнеры, virtualenv и vendored-артефакты, где версия могла быть закреплена. | GitHub advisory |
Риск возникает, когда middleware принимает security-решения по request.url.path. |
Проверять нужно не только зависимость, но и собственный код авторизации, allowlist, rate limit и routing rules. | X41 D-Sec |
| В downstream перечислены FastAPI, LiteLLM, vLLM, MCP-серверы и OpenAI-compatible proxy. | AI-сервисы нужно инвентаризировать как web-сервисы с отдельными границами доступа, а не как «внутренние утилиты». | OSTIF |
Особенно вредная реакция здесь — объявить «все MCP-серверы уязвимы». Это неправда. Риск зависит от версии Starlette, способа развёртывания, наличия reverse proxy, кода middleware и того, какие endpoint доступны за проверками. Но и успокаиваться фразой «это всего лишь Host header» нельзя: в агентных системах внутренний HTTP endpoint часто ближе к реальному действию, чем в обычном сайте.
Что проверить владельцам MCP-серверов и LLM proxy
Первый шаг — найти, где Starlette вообще присутствует. Проблема может прийти напрямую, через FastAPI или через готовый AI-инструмент, который поставляется контейнером. OSTIF отдельно предупреждает: pip list на хосте недостаточно, если сервис упакован в образ или vendor bundle.
Дальше стоит пройти короткий список:
- обновить Starlette до 1.0.1 или новее во всех средах, где она используется;
- пересобрать и заново выпустить контейнеры: обновления зависимости в репозитории недостаточно;
- найти в middleware обращения к
request.urlиrequest.url.path, особенно в auth, allowlist, rate limit и audit; - для security-решений использовать реальный ASGI path через
request.scope["path"]или endpoint-level авторизацию; - проверить, что reverse proxy действительно отклоняет некорректный
Hostheader до ASGI-сервера; - отдельно проверить vLLM, LiteLLM, MCP gateways, eval dashboards и OpenAI-compatible proxy, если они доступны из VPN, lab network или публичного интернета.
Публичный сканер на BadHost.org существует, но использовать его нужно аккуратно: проверяйте только свои endpoint или системы, на которые у вас есть разрешение. Для чужой инфраструктуры это уже не «любопытство», а несанкционированное тестирование.
Почему агентный контур требует более жёсткой границы
Старые веб-рекомендации здесь работают, но их мало. AI-агент открывает страницы, вызывает tools, читает файлы, ходит в API, управляет задачами и иногда запускает код. Поэтому путь к «внутреннему» endpoint в агентной системе может означать доступ к реальным действиям.
Это перекликается с нашим разбором о том, как автономный AI-пентестер сам становится целью. Атакующий бьёт не только по модели и не только по prompt. Он ищет связку из веб-слоя, credentials, tool execution и слабых границ между сервисами. BadHost как раз из этого класса: маленькая несогласованность в HTTP-интерпретации становится входом в более дорогой контур.
Для команд, которые строят агентов в production, практический вывод простой: MCP-сервер, LLM proxy и dashboard должны жить по тем же правилам, что и админка с доступом к деньгам или персональным данным. Нужны отдельные сервисные аккаунты, минимальные права, audit log, сетевые правила, нормальный reverse proxy и проверка зависимостей в образах.
Короткий вывод
BadHost / CVE-2026-48710 не доказывает, что MCP или FastAPI «сломаны». Он показывает, что агентная инфраструктура уже достаточно важна, чтобы обычные ошибки веб-стека давали непропорционально дорогой эффект.
Главное действие на сегодня: обновить Starlette до 1.0.1 или новее, пересобрать артефакты и проверить middleware, который принимает решения по request.url.path. Если в этом же контуре есть MCP, vLLM, LiteLLM или OpenAI-compatible proxy, проверку лучше считать не косметической, а срочной частью реагирования на уязвимость.
