LiteLLM та Starlette: ідеальний шторм вразливостей, що веде до неавтентифікованого віддаленого виконання коду

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Обидві кінцеві точки приймають повну конфігурацію MCP-сервера в тілі JSON-запиту, включаючи поля Cmd, args та env, які транспорт stdio використовує для запуску серверних процесів . Коли автентифікований користувач звертається до будь-якої з цих точок із такою конфігурацією, LiteLLM бере отримане значення Cmd та запускає його як дочірній процес на хост-машині, виконуючи його з тими ж привілеями операційної системи, що й сам процес проксі-сервера LiteLLM .

Спочатку BerriAI розкрила це як вразливість автентифікованого віддаленого виконання коду — зловмиснику потрібен був дійсний API-ключ для доступу до кінцевих точок, і не було жодної рольової перевірки, яка б обмежувала, хто може їх викликати. Навіть непривілейований внутрішній користувач із будь-яким дійсним API-ключем проксі міг виконувати довільні команди на хості . Але на цьому історія не закінчилася.

Обхід BadHost у Starlette, який знімає вимогу автентифікації

Друга вразливість — CVE-2026-48710, яку дослідники назвали "BadHost". Це помилка валідації заголовка хоста у фреймворку Starlette — легковаговому ASGI-фреймворку, що лежить в основі FastAPI, vLLM та тисяч інших Python-вебзастосунків, включно з LiteLLM . Уразливими є всі версії Starlette з 0.8.3 по 1.0.0 .

Першопричина полягає в розбіжності парсингу між тим, як Starlette маршрутизує вхідні запити, і тим, як він відновлює URL для логіки застосунку . Рівень ASGI-маршрутизації використовує необроблений HTTP-шлях із запиту, щоб вирішити, яка кінцева точка його обробляє. Але request.url — URL, який бачать middleware застосунку та декоратори — відновлюється шляхом конкатенації необробленого значення заголовка Host зі шляхом запиту, без належної валідації .

Вставляючи такі символи-роздільники, як ? або #, у заголовок Host, зловмисник може зробити так, що request.url.path виглядатиме зовсім інакше, ніж фактичний маршрутизований шлях . Middleware бачить нешкідливий шлях на кшталт /, тоді як маршрутизатор за лаштунками спрямовує запит до справжньої цільової кінцевої точки. Будь-яку автентифікаційну middleware, що довіряє request.url.path, можна тривіально обійти .

Об'єднання ланцюжка: від 8.7 до 10.0

Декоратор автентифікації LiteLLM перевіряє request.url.path, щоб визначити, чи потребує запит дійсний API-ключ. Обхід BadHost дозволяє зловмиснику маніпулювати цим URL так, що middleware автентифікації бачить шлях, який не потребує автентифікації, тоді як ASGI-маршрутизатор одночасно спрямовує запит на одну з уразливих кінцевих точок командної ін'єкції MCP .

Це усуває єдиний бар'єр контролю доступу, який стояв між інтернетом та довільним виконанням команд. Зловмисник без жодних облікових даних та попереднього доступу до мережі може надіслати один спеціально сформований HTTP-запит, який повністю обходить автентифікацію та виконує команди операційної системи на хості проксі-сервера LiteLLM . Horizon3.ai підтвердили, що повний ланцюжок працює, і привласнили йому комбіновану оцінку CVSS 10.0 — максимальний рівень небезпеки — оскільки він досягає неавтентифікованого віддаленого виконання коду .

Що зловмисники можуть зробити з таким доступом

Успішна експлуатація дає зловмисникам можливість виконання команд із привілеями процесу проксі-сервера LiteLLM. З цього моменту поверхня загрози швидко розширюється:

• Довільне виконання команд: Зловмисники можуть встановлювати бекдори, шкідливе програмне забезпечення, криптомайнери або будь-яке інше ПЗ, яке дозволяють привілеї хост-процесу .
• Масштабна крадіжка облікових даних: Проксі-сервер LiteLLM знаходиться між застосунками та десятками провайдерів LLM. Він зберігає API-ключі для OpenAI, Anthropic, Azure, AWS Bedrock, Google та інших підключених сервісів у своїй базі даних або змінних середовища . Експлуатація цієї вразливості дозволяє зловмисникам викрасти всі збережені облікові дані за одну операцію.
• Латеральне переміщення AI-інфраструктурою: Маючи викрадені хмарні API-ключі та shell-доступ до хоста проксі, зловмисники можуть проникнути в підключені сервіси, внутрішні MCP-сервери, векторні бази даних та downstream фреймворки агентів .
• Ширші наслідки для екосистеми: Вразливість BadHost у Starlette впливає на понад 400 000 залежних проєктів, включаючи застосунки FastAPI, сервери vLLM, розгортання MCP-серверів та фреймворки AI-агентів. Будь-які з них, які використовують автентифікаційну middleware на основі шляху на версіях Starlette до 1.0.1, так само вразливі до обходу автентифікації .

Чому дії CISA підвищують терміновість

Додавання CISA вразливості CVE-2026-42271 до каталогу KEV 8 червня 2026 року підтверджує, що вразливість не є теоретичною — зловмисники активно використовують її як зброю прямо зараз . Згідно з Оперативною директивою BOD 22-01, усі федеральні цивільні виконавчі органи США повинні виправити вразливості зі списку KEV протягом визначеного терміну. CISA також настійно рекомендує всім організаціям, державним і приватним, розглядати додавання до KEV як надзвичайний пріоритет для встановлення патчів .

Негайні кроки з усунення

Виправлення ланцюжкової експлуатації вимагає оновлень на двох фронтах, а також кількох заходів глибокоешелонованого захисту для усунення проблеми витоку облікових даних:

1. Оновіть LiteLLM до версії 1.83.7 або новішої. Цей реліз прибирає можливість тестових кінцевих точок MCP безпосередньо виконувати надані користувачем команди, повністю закриваючи вектор командної ін'єкції .
2. Оновіть Starlette до версії 1.0.1 або новішої. Патч валідує вхідні заголовки Host на відповідність специфікації URL та ігнорує заголовки, що містять недійсні символи, запобігаючи трюку з плутаниною шляхів, який лежить в основі обходу автентифікації .
3. Негайно змініть усі збережені облікові дані. Вважайте, що будь-який API-ключ, токен доступу або облікові дані бази даних, які коли-небудь зберігав проксі-сервер LiteLLM, були скомпрометовані. Змініть усі ключі OpenAI, Anthropic, Azure, AWS та інших провайдерів і перевірте білінгові панелі на предмет несанкціонованого використання .
4. Заблокуйте кінцеві точки на зворотному проксі або WAF. Як захід глибокоешелонованого захисту під час розгортання патчів, налаштуйте свій зворотний проксі або веб-фаєрвол на блокування будь-яких запитів до

   POST /mcp-rest/test/connection

   та

   POST /mcp-rest/test/tools/list

   ще до того, як вони досягнуть застосунку .
5. Проведіть ретроспективний аудит несанкціонованого доступу. Перевірте журнали проксі-сервера LiteLLM на предмет незвичайної активності на тестових кінцевих точках MCP, особливо запитів з неочікуваних IP-адрес або з маніпульованими заголовками Host .

Комбінована оцінка CVSS 10.0, активна експлуатація в дикій природі та статус KEV від CISA означають, що організації, які використовують LiteLLM або сервіси на базі Starlette, повинні розглядати це як надзвичайну подію, що вимагає негайного встановлення патчів та заміни облікових даних. Вікно можливостей між активною експлуатацією та витоком облікових даних вже відкрите.