Худший кошмар параноика стал реальностью. Ошибка в LiteLLM подменяет ответы ИИ на чужой код

ИИ-шлюзы всё чаще становятся точкой, через которую проходят не только запросы к моделям, но и ключи доступа, внутренние данные и команды агентов. Специалисты Obsidian Security раскрыли цепочку из трёх уязвимостей в LiteLLM, которая позволяет пользователю с минимальными правами получить полный контроль над прокси-сервером и выполнить код на хосте.

LiteLLM работает как единый шлюз между приложениями и более чем сотней поставщиков ИИ-моделей через интерфейс, совместимый с OpenAI. При компрометации такого узла атакующий получает доступ к ключам провайдеров, данным для расшифровки сохранённых учётных записей, а также к запросам и ответам, которые проходят через прокси.

Первая уязвимость, CVE-2026-47101 (8.8 по шкале CVSS 3.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), связана с проверкой прав. Обычный пользователь мог создать виртуальный API-ключ и сам указать для него разрешённые маршруты. LiteLLM не сверял поле allowed_routes с ролью пользователя, поэтому значение [«/*»] открывало доступ ко всем маршрутам, включая административные.

После обхода проверки становились доступны функции, которые рассчитывали на уже выполненную фильтрацию прав. Через CVE-2026-47102 (8.8 по шкале CVSS 3.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) пользователь мог обновить собственную запись и записать себе роль proxy_admin. А через CVE-2026-40217 (8.8 по шкале CVSS 3.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) открывался другой путь: механизм Custom Code Guardrail запускал администраторский Python-код через exec() без полноценной изоляции, из-за чего простая команда могла привести к выполнению кода на сервере.

Главный риск не ограничивается кражей ключей. LiteLLM находится между ИИ-агентом и моделью, поэтому захваченный шлюз может менять ответы на пути к агенту. В демонстрации Obsidian Security с Claude Code атакующий использовал встроенный механизм callback, подменил ответ модели на ложный вызов инструмента и добился запуска обратной оболочки на машине разработчика. Демонстрация тестовая — об использовании уязвимостей в реальных атаках речи пока не идёт.

Отдельно специалисты указали, что административный доступ к LiteLLM уже сам по себе близок к доступу к хосту. Поддержка MCP позволяет администратору регистрировать stdio MCP-серверы, которые прокси запускает как локальные подпроцессы. Такой механизм считается архитектурным компромиссом, а не отдельной ошибкой, поэтому обновление не меняет саму модель доверия.

BerriAI закрыла цепочку в LiteLLM v1.83.14-stable, выпущенной 2 мая. Для снижения риска нужно обновиться до этой версии или более новой, проверить всех пользователей с ролью proxy_admin, пересмотреть Custom Code Guardrail, изучить callback в config.yaml, проверить целостность развёрнутого кода и при подозрении на компрометацию сменить ключи провайдеров, учётные данные базы и сохранённые MCP-токены.