Шлюзы ИИ становятся поверхностью атаки — включение LiteLLM в KEV и путь через ключи, MCP и облако
Обход аутентификации MCP в BerriAI LiteLLM (CVE-2026-59822) попал в каталог KEV CISA, и Microsoft сообщает об атакующих, которые используют шлюзы LiteLLM, чтобы доставить XMRig. Исследование Wiz обнаружило, что примерно 1 из 10 из ~3,000 публичных экземпляров принимал ключ по умолчанию sk-1234 или работал без аутентификации. Мы рассматриваем, что значит положение, при котором инфраструктура ИИ является хранилищем учётных данных.
Эта статья была переведена машиной.
В сентябре 2026 года CISA добавила обход аутентификации MCP в BerriAI LiteLLM, CVE-2026-59822, в свой каталог Known Exploited Vulnerabilities (KEV) (2 сентября, по хронологии Wiz). Изъян позволяет произвольному токену Bearer установить действительный аутентифицированный сеанс на конечной точке MCP Streamable HTTP в LiteLLM, и он появился рядом с шестью другими эксплуатируемыми изъянами — включая SonicWall SMA 1000 и Sangoma Switchvox — в обновлении KEV начала сентября (по The Hacker News). LiteLLM — это шлюз ИИ с открытым исходным кодом, который хранит ключи API каждого настроенного поставщика LLM; по оценке Wiz он присутствует примерно в одной трети облачных сред.
Факты: (1) Исследование Wiz (опубликовано 9 сентября) обнаружило, что из примерно 3,000 экземпляров LiteLLM, обращённых в интернет, около 9.6% принимали мастер-ключ по умолчанию sk-1234 или вовсе не требовали аутентификации. В экземплярах без настроенной аутентификации каждому пользователю по умолчанию выдавался PROXY_ADMIN, что открывало функции администратора без учётных данных (с тех пор исправлено). (2) Имея права администратора, атакующий может использовать функцию сквозной конечной точки, чтобы проксировать запросы к произвольным внутренним URL — включая службу метаданных AWS, — а механизм пересылки заголовков x-pass- снимает требование сеансового токена IMDSv2, что позволяет кражу облачных учётных данных IAM. (3) В сентябре Microsoft сообщила об атакующих, которые связывают CVE-2026-42271 и CVE-2026-48710 (обход аутентификации Starlette «BadHost»), чтобы проникнуть в шлюзы LiteLLM и доставить майнер XMRig через двоичный файл ELF (по The Hacker News). Атаки на открытые экземпляры RAGFlow тем временем дали украденные ключи поставщиков LLM и метаданные, а не программы-вымогатели.
Анализ (отделён от фактов): эти истории показывают, что шлюзы ИИ вышли за стадию «LLMjacking» — расходования чужого бюджета API — и стали полноценным путём вторжения в облако. LiteLLM выполняет Python на стороне сервера при каждом запросе вывода, может проксировать запросы к произвольным внутренним URL и подключается к внешним инструментам через MCP. Это не просто хранилище ключей; это мост во внутреннюю сеть с возможностью выполнения. Активы, которые защищающаяся сторона предпочитает убирать под принцип устройства «это ИИ, держите его внутри», становятся для атакующих многоступенчатым путём к ключам, IAM и внутренним API за одним обходом аутентификации. Структурный разрыв между значениями по умолчанию, рассчитанными на опыт разработчика (sk-1234, PROXY_ADMIN при отсутствии настройки), и промышленным развёртыванием стоит назвать именно так.
Выводы для защиты: (1) Если вы запускаете LiteLLM, сначала обновитесь до v1.84.0 или новее (исправление CVE-2026-59822) и до v1.83.7 или новее (исправление CVE-2026-42271), а также до Starlette 1.0.1 или новее; подтвердите, что мастер-ключ по умолчанию изменён и что экземпляр не открыт в интернет. (2) Смените все хранимые ключи API поставщиков так, как если бы они были скомпрометированы в момент подтверждения экспозиции, и задайте пределы расходов, чтобы ограничить ущерб, когда ключ всё же уходит. (3) Функции, которые несут произвольное выполнение кода или проксирование произвольных URL, — MCP и сквозные конечные точки — рассматривайте как разрешения уровня агента: их нужно инвентаризировать отдельно и отключать по умолчанию. (4) Проверьте другие шлюзы ИИ и оркестраторы LLM в той же оптике: учётные данные по умолчанию, открытые функции администратора, проксирование внутренних URL. Это наш анализ, а не руководство поставщика.
Факты этой статьи взяты в первую очередь из исследования Wiz (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), выпуска исправления BerriAI LiteLLM (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) и каталога KEV CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog); сообщение The Hacker News служит вторичным источником (https://thehackernews.com/2026/09/cisa-adds-5-actively-exploited.html и https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html); дата включения в KEV — 2 сентября — следует хронологии Wiz. Разделы анализа отделены от фактического изложения. Отметим, что числа экземпляров и доля облачных сред являются оценками, которые зависят от времени и метода измерения.