ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

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

LiteLLM — это широко используемый шлюз искусственного интеллекта с открытым исходным кодом, который посредничает при вызовах более чем 100 поставщиков моделей через единый интерфейс, совместимый с OpenAI.

В результате взлома сервера становятся доступны все ключи поставщиков, хранящиеся на нем, секретные данные, необходимые для расшифровки сохраненных учетных данных, а также все запросы и ответы, проходящие через него.

Obsidian оценивает полную цепочку уязвимостей по шкале CVSS на 9,9, что соответствует уровню «Критический». BerriAI, компания-разработчик, включила полный набор исправлений в версию LiteLLM v1.83.14-stable, которая, согласно GitHub, была выпущена 2 мая. Обновитесь до этой версии или более поздней, чтобы устранить цепочку из трех уязвимостей CVE.

Первое звено — CVE-2026-47101, обход авторизации. Когда обычный пользователь (internal_user) генерирует виртуальный ключ API, LiteLLM сохраняет предоставленное вызывающим поле allowed_routes, не сверяя его с ролью пользователя.

Это поле должно ограничивать возможности ключа. Вместо этого прокси также рассматривает его как резервный допуск, поэтому пользователь, не являющийся администратором, может создать ключ с allowed_routes: ["/*"], подстановочным знаком, который охватывает все маршруты, включая доступные только администраторам. Такая же непроверенная запись встречается и в других конечных точках управления ключами, поэтому для исправления потребовалось три пулл-реквеста.

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

Один из них — CVE-2026-47102, повышение привилегий. Конечная точка /user/update позволяет пользователю редактировать свою собственную запись, но не ограничивает, в какие поля он может записывать данные. Самообновление с user_role: "proxy_admin" принимается и сохраняется, повышая статус вызывающего до полного администратора прокси. Org_admin может обратиться к этой конечной точке через легитимный, предусмотренный путь кода без необходимости обхода; внутренний пользователь по умолчанию достигает ее после CVE-2026-47101.

VulnCheck, который присвоил CVE, оценивает его на 8,7 по CVSS 4.0 и на 8,8 по 3.1.

Другой уязвимостью является CVE-2026-40217 — выход из песочницы в Custom Code Guardrail, который компилирует и запускает Python-код, предоставленный администратором. Производственные конечные точки запускали код через exec() без фильтрации на уровне исходного кода. Когда exec() получает словарь globals без __builtins__, Python незаметно вставляет полный модуль builtins, который предоставляет коду __import__, open и eval. Простой полезный груз, вызывающий os.system, был тогда достаточен для обратного шелла.

Отдельный путь на конечной точке тестовой площадки /guardrails/test_custom_code, обнаруженный независимо командой X41 D-Sec, обошел список запретов на основе регулярных выражений за счет перезаписи байт-кода во время выполнения. Оба случая завершились выполнением кода на стороне сервера.

LiteLLM находится в узком месте, поэтому его охват широк. Полная цепочка раскрывает мастер-ключ, ключ солевания, который расшифровывает сохраненные учетные данные, и URL базы данных. Она также раскрывает каждый настроенный ключ провайдера для OpenAI, Anthropic, Gemini, Bedrock, Azure и остальных.

Ключи в конфигурации или среде находятся в виде открытого текста; ключи в базе данных зашифрованы, но их можно восстановить с помощью солевого ключа. Все, что отправляется через шлюз — запросы и ответы — становится доступным для чтения, а в реальных развертываниях именно туда попадают личные данные, исходный код, внутренние тикеты и вставленные секретные данные.

Если прокси также работает как шлюз Model Context Protocol (MCP) или агентский шлюз, то в зону доступа попадают также токены OAuth и учетные данные инструментов.

Более серьезный риск заключается не в том, что злоумышленник читает, а в том, что он может переписать. Шлюз находится на линии связи между ИИ-агентом и моделью, поэтому взлом позволяет ему изменять ответы во время передачи.

Obsidian продемонстрировал это на примере Claude Code, проходящего через взломанный прокси. Это не вставка подсказок. Вместо того, чтобы убеждать модель вести себя некорректно, злоумышленник использует встроенный механизм обратного вызова LiteLLM — точку расширения, которая срабатывает при каждом запросе и никогда не отображается в интерфейсе администратора. Обратный вызов заменяет ответ модели на поддельный вызов инструмента и переписывает контекст проверки безопасности, чтобы действие выглядело как одобренное.

В демонстрации разработчик вводит одно слово — «hello» — и злоумышленник запускает обратный шелл на компьютере разработчика.

Независимо от этой цепочки, LiteLLM предоставляет proxy_admin намеренный путь для выполнения кода: его поддержка MCP позволяет администратору регистрировать MCP-серверы stdio, которые прокси запускает в качестве локальных подпроцессов. Это скорее компромисс в дизайне, чем баг, и патчи его не изменяют, поэтому доступ к admin фактически означает доступ к выполнению кода.

Obsidian воспроизвел обратный шелл таким образом в версии 1.88.0. Настоящая уязвимость в том же механизме stdio-MCP, CVE-2026-42271, позволяла вызывающим процессам запускать подпроцессы через конечные точки предварительного просмотра MCP LiteLLM; она была использована в реальных условиях и добавлена в каталог KEV CISA в начале этого месяца.

И это далеко не первые трудности LiteLLM в этом году. В марте в результате взлома цепочки поставок в двух выпусках LiteLLM на PyPI был установлен бэкдор, а в апреле критическая уязвимость SQL-инъекции была использована в течение 36 часов после раскрытия.

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

Обновитесь до версии v1.83.14-stable или более поздней — это первый релиз с полным набором исправлений. Затем проведите аудит. Повторно проверьте каждую учетную запись, имеющую права proxy_admin, и рассматривайте эту роль как доступ на уровне хоста. Проверьте все пользовательские ограничения Custom Code Guardrail на прокси.

Проверьте обратные вызовы, загруженные из config.yaml в litellm_settings.callbacks, поскольку они никогда не появляются в консоли и именно там может скрываться злоумышленник после получения RCE. Проверьте целостность развернутого кода, а не только конфигурации. Если есть подозрения в уязвимости, обновите ключи провайдера, учетные данные базы данных и любые сохраненные токены MCP.

Скомпрометированный прокси не просто утекает данные. Он находится между агентом и моделью и может подделывать ответы, на которые реагирует агент. Цепочка, которая приводит злоумышленника к этому, — это необоснованное доверие на каждом уровне: шлюз маршрута доверился полю, предоставленному вызывающим, обработчики доверились шлюзу маршрута, и никто на самом деле не проверил.