LiteLLM CVE: как пользователь захватывает AI-шлюз

Проверено 16 июня 2026 года. LiteLLM CVE-цепочка из трёх уязвимостей позволяет пользователю с низкими правами дойти до роли `proxy_admin` и выполнения кода на сервере LiteLLM Proxy. Исправление для полной цепочки есть в `v1.83.14-stable`, релиз опубликован 2 мая 2026 года.

LiteLLM - open-source LLM proxy / AI-шлюз: через него команды централизуют доступ к OpenAI, Anthropic, Gemini, Bedrock, Azure и другим провайдерам. Поэтому проблема не сводится к «ещё одному backend-RCE». Если атакующий забирает такой шлюз, он оказывается рядом с ключами провайдеров, master key, логами запросов, промптами, ответами моделей и настройками агентских инструментов.

Главный вывод: если self-hosted LiteLLM стоит внутри компании, проверка версии и прав администраторов должна быть срочной задачей. Obsidian Security не заявляла об активной эксплуатации именно этой новой цепочки, но похожие LiteLLM-инциденты 2026 года уже переходили из advisory в реальные попытки атак очень быстро.

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

Obsidian Security 11 июня 2026 года раскрыла цепочку из CVE-2026-47101, CVE-2026-47102 и CVE-2026-40217. Сценарий начинается не с администратора, а с обычного `internal_user`. По отдельности две первые уязвимости оценены как высокие: 8,7 по CVSS 4.0 и 8,8 по CVSS 3.1. Полную цепочку Obsidian оценивает в 9,9, потому что она соединяет обход прав, повышение роли и серверное выполнение кода.

Это важно для команд, которые используют LiteLLM как корпоративную прослойку между приложениями, агентами и провайдерами моделей. В такой архитектуре шлюз часто знает больше, чем отдельное приложение: какие модели доступны, какие ключи выданы, какие бюджеты и лимиты стоят у команд, какие guardrails и callbacks срабатывают на запросах.

Почему LiteLLM CVE опаснее обычной уязвимости в сервисе

LiteLLM сам описывает Proxy Server как self-hosted OpenAI-compatible gateway с virtual keys, cost tracking и admin UI. Документация также показывает роль LiteLLM как единого шлюза для LLM, агентов и MCP. Это удобная архитектура: один контрольный слой вместо набора разрозненных интеграций.

Но безопасность у такого слоя тоже централизуется. Если злоумышленник получает права администратора или RCE внутри прокси, он может читать и менять не только одну функцию приложения. В зоне риска оказываются ключи провайдеров, `LITELLM_MASTER_KEY`, salt key для расшифровки сохранённых credentials, `DATABASE_URL`, история запросов, ответы моделей и настройки маршрутизации.

Для AI-агентов риск ещё шире. Шлюз стоит между агентом и моделью, а значит может видеть tool calls и ответы, на которые агент дальше опирается. Obsidian в демонстрации показала не prompt injection, а компрометацию инфраструктурного слоя: callback на стороне LiteLLM подменяет ответ модели и контекст проверки, после чего downstream-агент может выполнить опасное действие как будто оно разрешено.

Как цепочка превращает internal_user в proxy_admin

Первое звено - CVE-2026-47101. По данным NVD, LiteLLM до 1.83.14 позволял аутентифицированному `internal_user` создать API key с доступом к маршрутам, которые его роль не должна разрешать. Проблема в поле `allowed_routes`: при создании ключа оно сохранялось без проверки относительно полномочий вызывающего пользователя. Такой ключ можно было использовать для доступа к admin-only routes.

Второе звено - CVE-2026-47102. NVD и GitHub Advisory описывают проблему в `/user/update`: endpoint ограничивал пользователя собственной записью, но не защищал отдельные поля. Поэтому пользователь мог записать себе `user_role: "proxy_admin"`. Для `org_admin` это работало без дополнительной цепочки; для `internal_user` путь открывался после первого звена.

Третье звено - CVE-2026-40217. Это уязвимость в Custom Code Guardrail. NVD формулирует её как возможность выполнить произвольный код через bytecode rewriting на `/guardrails/test_custom_code`. Obsidian дополнительно описывает production-путь через guardrail CRUD endpoints: пользовательский Python-код компилировался и выполнялся через `exec()`, а sandbox оказался недостаточным.

Мы намеренно не приводим exploit payload. Для защитной работы достаточно понять порядок: ключ с расширенными маршрутами, смена роли, затем доступ к механизму, который исполняет код внутри процесса прокси.

Не путайте эту цепочку с CVE-2026-42208

В 2026 году у LiteLLM уже было несколько громких инцидентов. Новый материал не должен смешивать их в одну кашу.

CVE-2026-42208 - отдельная SQL injection в проверке API key. LiteLLM в официальном security update писал, что затронуты версии `v1.81.16` через `v1.83.6`, исправление есть в `v1.83.7` и новее, а рекомендованной версией на тот момент была `v1.83.10-stable`. NVD оценивает эту SQLi как критическую: 9,8 по CVSS 3.1, а CISA добавила её в KEV 8 мая 2026 года.

Это полезный контекст, но не та же цепочка. CVE-2026-42208 начиналась до аутентификации и била по базе данных через Bearer header. Цепочка Obsidian начинается с низкопривилегированного пользователя и идёт через управление ключами, смену роли и Custom Code Guardrail. Для читателя это разные проверки: одно - история SQLi и query logs, другое - роли, маршруты, guardrails и callbacks.

Есть и мартовский supply-chain эпизод с LiteLLM на PyPI. Мы уже разбирали мартовский supply-chain взлом LiteLLM на PyPI. Он важен как сигнал по тому же проекту и той же зоне риска, но это другой интент: там проблема была в цепочке поставки пакета, здесь - в правах и исполняемых расширениях LiteLLM Proxy.

Что делать, если self-hosted LiteLLM уже используется

Минимальное действие - обновиться до `v1.83.14-stable` или более новой версии. Релиз `v1.83.14-stable` на GitHub опубликован 2 мая 2026 года; в заметках к релизу есть правки, напрямую связанные с проверками прав вызывающего пользователя и полями маршрутов ключей.

Но один апдейт не закрывает вопрос расследования. Если прокси был доступен широкой внутренней сети, а обычные пользователи могли создавать ключи, обновление нужно сопровождать аудитом.

• Проверьте текущую версию LiteLLM Proxy и все инстансы, включая тестовые окружения.
• Найдите ключи с широкими `allowed_routes`, особенно wildcard-доступом и доступом к admin-only маршрутам.
• Перепроверьте пользователей с ролью `proxy_admin`: кто получил роль, когда и через какой endpoint.
• Посмотрите изменения в `/user/update`, `/user/bulk_update`, `/key/generate` и `/key/update` за период до обновления.
• Проведите ревью Custom Code Guardrail: что исполняется, кто менял код, совпадает ли он с ожидаемой конфигурацией.
• Проверьте callbacks в `litellm_settings.callbacks`; Obsidian отдельно отмечает, что такие callbacks могут быть не видны в admin UI, но исполняться на каждом запросе.
• При признаках компрометации ротируйте `LITELLM_MASTER_KEY`, ключи провайдеров, учётные данные БД, MCP/OAuth tokens и связанные service-account tokens.
• Проверьте, не проходит ли через LiteLLM чувствительный контент: PII, исходный код, внутренние тикеты, customer data и секреты, вставленные в промпты.

Отдельный слой - API-ключи провайдеров. Внутри AI-инфраструктуры они часто становятся общей точкой отказа: один ключ оплачивает запросы, открывает доступ к данным и даёт возможность маскировать чужой трафик под легитимный. Мы отдельно разбирали, почему API-ключи в AI-инфраструктуре становятся точкой риска, и LiteLLM - как раз тот случай, где эта проблема концентрируется в одном сервисе.

Что проверить в архитектуре AI-агентов

Если LiteLLM используется только как thin proxy к моделям, ущерб уже серьёзный. Если он связан с агентами, MCP и внутренними инструментами, риск становится операционным.

Здесь полезно мыслить не только CVE-номерами, а цепочкой доверия. Агент доверяет модели, модель получает ответ через шлюз, шлюз может запускать callbacks и guardrails, а часть действий агента уходит в tools. Компрометация прокси значит, что атакующий может вмешаться до того, как ответ попадёт к агенту и человеку.

• Не давайте агентам использовать один и тот же LiteLLM key для чтения, записи и административных действий.
• Разделяйте ключи по командам, сценариям и средам; ключ для dev-агента не должен иметь доступ к production-маршрутам.
• Логируйте tool calls и ответы модели так, чтобы можно было увидеть подмену, а не только итоговое действие агента.
• Ограничивайте callbacks и custom guardrails: это исполняемая логика, а не «настройка безопасности» по умолчанию.
• Для MCP и локальных tool runners используйте изоляцию: отдельный пользователь, read-only filesystem, deny-by-default сеть.

В материале про безопасность агентских систем мы уже писали: агентная система ломается не только через модель. У неё есть окружение, инструменты, память, права и каналы вывода. LiteLLM как шлюз находится прямо на этой границе.

FAQ

Какие версии LiteLLM надо обновлять?

Для полной цепочки Obsidian ориентир - версии до `v1.83.14-stable`. Для старой SQLi CVE-2026-42208 официальный LiteLLM security update называл затронутыми `v1.81.16` через `v1.83.6` и фикс в `v1.83.7+`. Если вы не уверены, какой именно путь применим к вашему инстансу, проще и безопаснее обновиться до актуальной stable-версии и отдельно провести аудит.

Нужно ли атакующему быть администратором?

Для новой цепочки - нет. Сценарий начинается с `internal_user`, затем через CVE-2026-47101 появляется доступ к admin-only маршрутам, через CVE-2026-47102 роль меняется на `proxy_admin`, а CVE-2026-40217 даёт путь к выполнению кода.

Есть ли подтверждённая эксплуатация именно этой цепочки?

По состоянию на 16 июня 2026 года в проверенных источниках мы не нашли подтверждения активной эксплуатации именно цепочки CVE-2026-47101 / CVE-2026-47102 / CVE-2026-40217. Но отдельные LiteLLM-уязвимости уже эксплуатировались: CVE-2026-42208 добавлена CISA в KEV, а Sysdig описывала попытки эксплуатации после раскрытия.

Почему `proxy_admin` так опасен?

Потому что это не только доступ к интерфейсу. В LiteLLM рядом находятся ключи, маршрутизация запросов, guardrails, callbacks, MCP/agent-интеграции и логи. Для обычного SaaS это высокий риск; для AI-шлюза это риск подмены и наблюдения за тем, что дальше делают агенты и приложения.

Главное

LiteLLM CVE-цепочка показывает слабое место корпоративных AI-шлюзов: они становятся удобной точкой управления, но вместе с этим собирают ключи, промпты, ответы, роли и исполняемые расширения. Компрометация такого узла бьёт не по одному endpoint, а по всему пути между приложением, агентом и моделью.

Если LiteLLM есть в вашей сети, не ограничивайтесь чтением advisory. Обновите Proxy до `v1.83.14-stable` или новее, проверьте роли и ключи, отдельно посмотрите Custom Code Guardrail и callbacks, а при подозрении на компрометацию ротируйте ключи провайдеров и инфраструктурные секреты. Это скучная работа, но именно она отделяет «мы поставили патч» от реального снижения риска.

Источники и проверка фактов

Факты, даты, CVE-номера, версии и рекомендации проверены 16 июня 2026 года. Статусы advisory, оценки CVSS и рекомендации поставщиков могут измениться после публикации.

• Obsidian Security: Breaking LiteLLM: From Low-Privilege User to Admin and RCE, 11 июня 2026 года.
• The Hacker News: LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers, 15 июня 2026 года.
• NVD: CVE-2026-47101 - описание allowed_routes и оценка CVSS.
• NVD: CVE-2026-47102 - описание `/user/update` и смены `user_role`.
• NVD: CVE-2026-40217 - Custom Code Guardrail / RCE.
• GitHub Release: LiteLLM v1.83.14-stable, 2 мая 2026 года.
• LiteLLM docs: Getting Started - определение LiteLLM, LLM Gateway и поддержка провайдеров.
• LiteLLM docs: Custom Code Guardrail - официальное описание guardrail-механизма.
• LiteLLM Security Update: CVE-2026-42208, 29 апреля 2026 года.
• NVD: CVE-2026-42208 - SQL injection, CVSS и CISA KEV context.
• Sysdig: CVE-2026-42208 targeted SQL injection, контекст по наблюдаемым попыткам эксплуатации.

Читайте также

• Взлом LiteLLM на PyPI: как хакеры превратили ИИ-библиотеку в кражу паролей
• Google Cloud и Gemini API keys: где ломается AI security
• Безопасность агентских систем: атаки, GPU-часы и MEMO