Уязвимость Starlette обходит аутентификацию в FastAPI-сервисах

Коротко о главном

2 сентября 2026 года CISA внесла CVE-2026-48710 в каталог активно эксплуатируемых уязвимостей. Проблема — в популярном Python-фреймворке Starlette, на котором построен FastAPI: он не проверяет HTTP-заголовок Host перед сборкой request.url, из-за чего атакующий может подделать путь и обойти проверки доступа в middleware. Исправление вышло в Starlette 1.0.1 — обновиться нужно сейчас.

Для команд, которые держат публичные API на FastAPI или Starlette, это не абстрактная «средняя» уязвимость: её уже применяют в реальных атаках. Если ваша аутентификация или авторизация где-то опирается на request.url.path, а не на «сырой» путь запроса, — вы под ударом. Первый шаг — инвентаризировать backend-сервисы и проверить версию Starlette в зависимостях.

Это классический случай, когда дыра прячется не в вашем коде, а в транзитивной зависимости фреймворка. Разбираем ниже, как устроена атака, почему она опасна в связке с другими CVE и как выстроить аудит кода и зависимостей, чтобы такие вещи всплывали до, а не после инцидента.

Что произошло

CVE-2026-48710 — это уязвимость класса HTTP Request/Response Smuggling (CWE-444) с оценкой CVSS 6.5. Она затрагивает все версии Starlette до 1.0.1. 2 сентября 2026 года CISA добавила её в каталог Known Exploited Vulnerabilities (KEV) вместе с ещё шестью уязвимостями — среди них флаги в Sangoma Switchvox, Kestra OSS, JFrog Artifactory, BerriAI LiteLLM и два SSRF/command-injection в SonicWall SMA1000. Попадание в KEV означает не «теоретический риск», а зафиксированную эксплуатацию в реальных условиях.

Starlette — это ASGI-фреймворк, который сам по себе используется для лёгких сервисов, но куда шире известен как фундамент FastAPI. Именно поэтому радиус поражения велик: любое приложение на FastAPI тянет Starlette как зависимость и наследует эту уязвимость, пока не обновит библиотеку до безопасной версии.

Как устроена уязвимость

Корень проблемы — отсутствие валидации заголовка Host. Свойство request.url в Starlette собирает URL, конкатенируя контролируемый атакующим заголовок Host с путём запроса, и затем заново парсит получившуюся строку — не сверяя Host с грамматикой RFC 9112 и RFC 3986.

Из-за этого встраивание символов /, ? или # в значение Host сдвигает границы пути, query-строки и фрагмента. В результате request.url.path начинает расходиться с тем путём, который реально пришёл «по проводу». Маршрутизатор фреймворка при этом отрабатывает исходный, настоящий путь — а вот middleware, которое принимает решение о доступе на основе request.url.path, видит подделанное значение.

Практический итог: неаутентифицированный удалённый злоумышленник отправляет запрос с хитрым заголовком Host, middleware проверяет «безопасный» подставной путь и пропускает запрос, а защищённый эндпоинт всё равно исполняется. Это обход аутентификации на маршрутах, которые должны были быть закрыты — CWE-1289 (некорректная проверка «эквивалентности») в связке с request smuggling.

Почему это опаснее, чем CVSS 6.5

Формальные 6.5 балла не отражают реального веса, потому что уязвимость работает как звено в цепочке. По данным The Hacker News, CVE-2026-48710 связывали с CVE-2026-42271 (CVSS 8.7), чтобы обойти аутентификацию и добиться удалённого выполнения кода на уязвимых развёртываниях LiteLLM. С этой атакой связывают группировку вымогателей Qilin, а на скомпрометированные системы разворачивали майнер XMRig.

Это типичный сценарий современных атак: «средняя» уязвимость обхода аутентификации становится точкой входа, а дальше в дело идёт вторая CVE, дающая RCE. По отдельности каждая может выглядеть терпимой — вместе они дают полный контроль над сервисом. Именно поэтому наличие в каталоге KEV сразу нескольких компонентов (Starlette, LiteLLM, JFrog Artifactory) — сигнал, что атакующие целенаправленно бьют по инфраструктуре разработки и ИИ-сервисам.

Что это значит для команд разработки

Первое — это проблема управления зависимостями, а не только «безопасности». Вы можете не писать ни строки на Starlette напрямую, но если в проекте есть FastAPI, Starlette уже у вас в дереве зависимостей. Уязвимость наследуется молча, и её не видно в вашем собственном коде — её видно только в lock-файле.

Второе — под особым риском те, кто реализовал авторизацию на уровне middleware по пути запроса: проверки вида «если путь начинается с /admin — требовать роль» или маршрутизация доступа по префиксам URL. Если такое middleware читает request.url.path, а не scope["path"], атака его обманывает. Это распространённый паттерн в API-шлюзах и внутренних сервисах.

Третье — экспозиция. Публичные API, ИИ-прокси и internal-сервисы, доступные из корпоративной сети, одинаково в зоне поражения, потому что для атаки достаточно одного HTTP-запроса без аутентификации. Наличие подтверждённой эксплуатации и связки с вымогателями делает промедление дорогим.

Как действовать

Обновите Starlette до 1.0.1 или выше. В этой версии Host валидируется по грамматике RFC 9112 §3.2 / RFC 3986 при сборке request.url, а для некорректных значений происходит откат к scope["server"]. Для проектов на FastAPI это означает поднять именно транзитивную зависимость Starlette, а не только сам FastAPI.

Проверьте зависимости: пройдитесь по lock-файлам (poetry.lock, requirements.txt, uv.lock) во всех сервисах, а не только в «главном» приложении — уязвимая версия часто оседает в мелких вспомогательных сервисах, о которых забыли.

Проверьте логику авторизации: если middleware принимает решения о доступе, убедитесь, что оно опирается на scope["path"] из ASGI-области, а не на реконструированный request.url.path. Это защита в глубину даже после патча.

Сверьтесь с каталогом KEV: если у вас есть развёртывания LiteLLM, JFrog Artifactory или SonicWall SMA1000 — они попали в тот же список 2 сентября, и их тоже нужно закрыть приоритетно.

Встройте проверку в конвейер: добавьте сканирование зависимостей (SCA) в CI, чтобы новые CVE в сторонних библиотеках всплывали автоматически, а не при разборе инцидента.

Часто задаваемые вопросы

Затрагивает ли это FastAPI? Да. FastAPI построен на Starlette и использует его как базовый фреймворк, поэтому приложения на FastAPI уязвимы, пока зависимость Starlette не обновлена до 1.0.1 или новее.

Какие версии Starlette уязвимы? Все версии до 1.0.1. Исправление вошло в 1.0.1: там добавлена валидация заголовка Host при сборке request.url и откат к scope["server"] для некорректных значений.

Почему CVSS всего 6.5, если это критично? Сама по себе уязвимость даёт обход аутентификации (средний балл), но в реальных атаках её связывают с CVE-2026-42271 для достижения RCE против LiteLLM. Оценивать нужно риск цепочки, а не одной CVE.

Как понять, что мы под ударом? Если хоть один сервис использует FastAPI или Starlette версии ниже 1.0.1 и доступен по HTTP, вы потенциально уязвимы. Особый риск — если авторизация в middleware опирается на request.url.path.

Что делать в первую очередь? Обновить Starlette до 1.0.1+ во всех сервисах, затем проверить, что логика доступа читает «сырой» путь из ASGI-scope, и добавить SCA-сканирование зависимостей в CI.

Источники

CISA — CISA Adds Seven Known Exploited Vulnerabilities to Catalog, 2 сентября 2026 года (первоисточник).

The Hacker News — CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners, 2026.

GitLab Advisory Database / Snyk — CVE-2026-48710: Starlette missing Host header validation, 2026.