CVE-2026-35029 в LiteLLM: как урезанная роль вскрывает все ключи проекта

7 апреля 2026 года, буквально на следующий день после раскрытия CVE-2026-35029, honeypot-сенсоры (приманки) поймали первые пробы против LiteLLM — популярного AI-gateway (шлюза к LLM), через который приложения ходят к десяткам провайдеров моделей под единым API. Брешь позволяет пользователю с урезанной ролью дотянуться до админ-функций и вытащить самое ценное: мастер-ключ, ключи провайдеров, доступы к базам и облаку.

Что случилось с LiteLLM

Брешь CVE-2026-35029 живёт в эндпоинте /config/update. Проблема в авторизации: аутентифицированный пользователь с ограниченной ролью (например proxy_admin_viewer) получает доступ к операциям, для которых нужна роль proxy_admin. Роль есть, прав быть не должно — а сервер их всё равно отдаёт. Затронуты все версии до 1.83.0.

Масштаб охоты видно по цифрам. Ханипот-проект Zenity насчитал около 3 900 запросов к админ-API LiteLLM с февраля по июнь 2026 года, и примерно 1 000 из них били точно в /config/update. Атакующие подбирали мастер-ключ, генерировали API-ключи, заводили аккаунты, перечисляли пользователей и удаляли модели. Как сообщает Cyber Security News, первые пробы пошли уже 7 апреля, на следующий день после публикации CVE.

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

Как из «зрителя» получается администратор

Дальше начинается самое интересное. Получив админ-доступ через /config/update, атакующий переписывает параметр UI_LOGO_PATH и подставляет туда путь к чувствительному файлу, например /app/.env или /proc/self/environ. После этого файл читается через неаутентифицированный /get_image, который честно отдаёт «логотип». Только вместо картинки в ответе лежит содержимое переменных окружения. Одна безобидная с виду настройка превращается в произвольное чтение файлов.

А в окружении LiteLLM обычно хранится всё, ради чего и приходят:

• мастер-ключ самого LiteLLM;
• API-ключи провайдеров моделей;
• пароли и строки подключения к базам данных;
• учётные данные AWS и другого облака;
• токены систем наблюдаемости (observability).

Сценарий на этом не заканчивается. Через тот же /config/update можно перезаписать UI_USERNAME и UI_PASSWORD и захватить дашборд целиком, либо зарегистрировать вредоносный pass-through-обработчик (сквозной обработчик запросов) и получить выполнение кода на сервере (RCE).

Почему шлюзы к LLM превратились в лакомую цель

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

Инфраструктура вокруг ИИ выросла быстрее, чем практики её защиты. Gateway, векторные базы, оркестраторы агентов, кэши промптов — этот слой редко проходит через тот же аудит, что и классические веб-сервисы. А ошибка тут банальная: проверили, что пользователь залогинен, но забыли проверить, что ему можно. Broken access control (нарушение контроля доступа) не стал реже оттого, что рядом появились нейросети. Скорее наоборот: поверхность выросла, а глаз на неё почти никто не положил.

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

Что делать

Первое и очевидное: обновить LiteLLM до 1.83.0, где брешь закрыта. Дальше по инфраструктуре:

• убрать control-plane (панель управления) из публичного интернета и держать её во внутреннем контуре;
• спрятать админ-эндпоинты за reverse-proxy (обратный прокси) с отдельной аутентификацией;
• задать сильный уникальный мастер-ключ, а не тот, что гуляет по документации и примерам;
• провести ротацию всех секретов, которые могли утечь: ключи провайдеров, доступы к БД, облачные учётки, токены наблюдаемости;
• завести мониторинг на подозрительные обращения к /config/update, /get_image, /key/generate, /user/new, /model/delete и /scim/.

И проверять весь этот слой не по чек-листу «включён ли HTTPS», а руками. Такие дыры в авторизации всплывают именно тогда, когда пентест ИИ и LLM-приложений смотрит не только на промпты и джейлбрейки модели, но и на обвязку вокруг неё — шлюзы, ключи, роли, служебные эндпоинты. Модель можно оставить нетронутой, а весь бизнес утащить через прокси перед ней.

Итог

CVE-2026-35029 — это не про хитрый эксплойт, а про забытую проверку прав в сервисе, которому доверили все ключи разом. Патч есть, приманки уже считают тысячи попыток. Обновитесь, уберите панель из интернета и проверьте, кто на самом деле может дёргать ваши админ-эндпоинты.