Wiz: почти каждый десятый публично доступный шлюз LiteLLM принимает демонстрационный админ-ключ sk-1234

9 сентября 2026 года Wiz Research опубликовала исследование LiteLLM — открытого AI-шлюза, который находится между приложениями и поставщиками моделей, которым они платят, — и сообщила, что 294 из 3 074 развёртываний LiteLLM, доступных ей в публичном интернете, — 9,6%, почти каждое десятое, — принимали sk-1234, пример главного ключа, приведённый в собственной документации проекта по настройке, или вообще не требовали учётных данных. Эта строка не обычный API-ключ: в LiteLLM она одновременно является учётными данными администратора и переключателем, включающим аутентификацию, поэтому тот, кто её предъявит, может прочитать каждый ключ поставщика моделей, хранящийся на шлюзе, наблюдать за каждым запросом и ответом, проходящим через него, и получить доступ к каждому серверу инструментов, подключённому по Model Context Protocol. Соавторы Wiz Амитай Коэн и Яара Шрики связали этот доступ с выполнением кода с правами root и с кражей облачных учётных данных IAM хоста. Этот материал опирается на отчёт Wiz, собственные рекомендации LiteLLM по безопасности и последовавший перечень CISA Known Exploited Vulnerabilities, а архив инцидентов ИИ хранит эту запись вместе с соседними записями, у каждой из которых есть собственные источники, уровень серьёзности и степень уверенности.

Дата публикации — единственная дата, которая есть в записи, и это дата публикации. Сканирование, лежащее в основе заголовка, было проведено в феврале 2026 года; две уязвимости в коде, которые описывает Wiz, получили исправления в выпусках не позднее середины мая — в релизах, которые, согласно собственным записям проекта, датируются мартом и маем; идентификаторы CVE были присвоены в июле; а запись в каталоге появилась в сентябре. Почти всё в отчёте уже устарело к моменту его публикации, и это во многом составляет суть аргументации отчёта.

9,6% — это результат одного сканирования, а Wiz утверждает, что его собственное августовское повторное сканирование нельзя с ним сравнивать.

Методика измерения проста, и Wiz прямо описывает свой метод: 3 074 доступных из интернета прокси-сервера LiteLLM, обнаруженных через Shodan в феврале 2026 года, каждый проверялся на то, пройдёт ли аутентификацию с указанным в документации примером ключа. Из них 294 прошли. В этой группе у 191 вообще не был настроен мастер-ключ, и они приняли бы любую предложенную строку; остальные оставили на месте заполнитель из руководства по настройке. Ни один из этих сценариев отказа не требует наличия программной ошибки. Обоим достаточно лишь адреса шлюза и значения, напечатанного в собственном README проекта.

Это также сканирование, выполненное одним поставщиком. Цифру Wiz 10 сентября повторила инициатива AI Safety Initiative организации Cloud Security Alliance, а в тот же день — The Hacker News, но обе воспроизводят её с указанием источника, и для этой статьи не было найдено независимого воспроизведения цифры 3 074. Wiz провела второе сканирование в августе 2026 года и обнаружила более 85 000 экземпляров — примерно в двадцать семь раз больше февральского показателя. Компания утверждает, что большинство из них, судя по всему, являются ханипотами или тестовыми развертываниями, и что эти два показателя нельзя сравнивать. Актуальной цифры экспонированных систем нет, и любая статья, приводящая такую цифру, приводит февральскую.

Ещё одна цифра в отчёте — это собственная телеметрия Wiz, а не результат сканирования: компания утверждает, что LiteLLM присутствует примерно в трети облачных сред, которые она наблюдает. Это взгляд поставщика на собственную клиентскую базу, и к нему стоит относиться с осторожностью, но это объясняет, почему исследователи рассматривали неверную конфигурацию шлюза как проблему облака, а не приложения.

Мастер-ключ одновременно является учётными данными администратора и переключателем, который включает аутентификацию.

Дизайн LiteLLM возлагает на один секрет две задачи. Мастер-ключ аутентифицирует административные запросы, и именно его наличие вообще включает аутентификацию: без мастер-ключа и без конфигурации JWT или OAuth2 прокси работает открыто и принимает любой запрос. Wiz подошла к кодовой базе с Claude Code от Anthropic в поисках функций, которые принимают ввод, контролируемый пользователем, и передают его в контекст выполнения, и обработчик аутентификации оказался одной из трёх поверхностей, которые она отметила.

До v1.82.0-stable последствие этой второй задачи было хуже, чем открытый прокси. Wiz обнаружила, что если мастер-ключ не был задан, обработчик аутентификации назначал роль PROXY_ADMIN каждому входящему запросу, поэтому неаутентифицированный вызывающий не просто допускался, а допускался как администратор. Pull request #22095, упомянутый в отчёте, изменил роль по умолчанию на INTERNAL_USER и добавил проверку прав администратора для эндпоинтов guardrail.

Административный доступ к шлюзу — это не узкая привилегия. Экземпляр хранит API-ключ для каждого провайдера, к которому он маршрутизирует запросы, и именно это делает его целью для LLMjacking — выполнения рабочих нагрузок моделей за счёт жертвы. Он видит промпты и ответы. Он устанавливает исходящие подключения к серверам инструментов MCP, которые при внутреннем развёртывании, вероятно, включают трекеры задач, чат, базы данных и конвейеры развёртывания.

Wiz также продемонстрировала путь от этой административной роли к облачной идентичности хоста. LiteLLM позволяет администратору зарегистрировать сквозной маршрут на любой целевой URL, при этом целевой адрес не проверяется на принадлежность к частным диапазонам адресов, localhost или адресу облачных метаданных. Если направить маршрут на службу метаданных экземпляра, возвращаются учётные данные IAM, под которыми выполняется рабочая нагрузка. Переключение службы метаданных на IMDSv2, который обычно предотвращает этот класс подделки запросов, требуя отдельно полученный токен сеанса, не помогает: LiteLLM перенаправляет на целевой адрес любой заголовок с префиксом x-pass- с удалением этого префикса, поэтому заголовок с токеном можно протащить. Wiz говорит, что эта функция, вероятно, работает как задумано в рамках модели угроз, доверяющей администраторам, и поэтому не имеет CVE и исправления.

Последний абзац — это демонстрация, а не наблюдаемая атака. The Hacker News, сообщая об исследовании 10 сентября, утверждает, что ни один источник не сообщает, что кто-либо делал это против реального развёртывания, и что для этого сначала требуется доступ администратора. Формулировка Wiz та же: pass-through — это свойство дизайна, которое становится уязвимостью только тогда, когда учётные данные администратора представляют собой строку из документации.

8.8 и 2.1 — это оценки одной и той же сети с разных стартовых позиций

Две CVE содержат технические выводы, и их опубликованные оценки едва ли могут быть более далёкими друг от друга.

CVE-2026-59822 — это обход аутентификации в MCP, и в рекомендации LiteLLM ему присвоена оценка High — 8,8 по CVSS 4.0, при этом не требуются привилегии, не требуется взаимодействие с пользователем и отсутствуют требования к атаке. Конечная точка MCP имеет собственный обработчик аутентификации, рассчитанный на приём либо ключа LiteLLM, либо токена OAuth2, предназначенного для вышестоящего сервера инструментов. Когда токен не проходил проверку LiteLLM, обработчик перехватывал ответ 401 и вместо отклонения запроса подставлял пустой объект аутентификации. Поэтому любой Bearer-токен создавал действительный сеанс MCP, включая токен из одного символа: proof of concept от Wiz отправляет bearer-токен из одной буквы и получает в ответ идентификатор сеанса. Уязвимость исправлена в версии 1.84.0.

CVE-2026-59821 — это уязвимость механизма guardrail, и в рекомендациях того же проекта она оценена как Low, 2.1, с требованием высоких привилегий и наличием требований к атаке. Функция custom code guardrail позволяет администратору отправить код Python, который сервер компилирует и выполняет. Тестовый эндпоинт Web UI проверял код по списку запрещённых шаблонов и удалял builtins перед запуском; production-эндпоинты создания и обновления не делали ни того, ни другого. Python восстанавливает builtins, когда они отсутствуют, поэтому отправленный код получал доступ к стандартной библиотеке. Proof of concept от Wiz регистрирует guardrail, который выполняет shell-команду во время регистрации — до любого запроса к модели — и возвращает вывод команды в качестве причины блокировки; в его тесте вывод был получен от имени root. Уязвимость исправлена в v1.82.0-stable.

Оба описания совместимы, и примиряющее предложение содержится в самом рекомендательном документе: LiteLLM отмечает, что в развертываниях без настроенного мастер-ключа вызывающие стороны могли рассматриваться как администраторы прокси, и именно это сделало эндпоинты guardrail доступными. Оценка 2.1 предполагает привилегированного пользователя. Цепочка Wiz — это то, что происходит, когда ключ по умолчанию делает каждую вызывающую сторону привилегированной. Ни одна из оценок не ошибается относительно своей исходной позиции; они расходятся в том, как часто эта позиция достаётся бесплатно.

С утверждением Wiz о том, что после 1.82.0 атакующий, владеющий ключом по умолчанию, мог выполнять код только внутри песочницы, связана одна оговорка. The Hacker News указывает на отдельное уведомление от мая 2026 года, CVE-2026-40217, в котором описывается выход из этой песочницы с помощью методов байт-кода в версиях с 1.81.8 до (не включая) 1.83.10 — внутри процесса прокси, который, согласно уведомлению, работает от имени root в образе контейнера по умолчанию. Для доступа к этой конечной точке нужны учётные данные администратора прокси, а это как раз и есть мастер-ключ.

Оценка 8.8 также не является универсальной. В исследовательской заметке Cloud Security Alliance отмечается, что в рекомендательном бюллетене GitLab для той же уязвимости указана базовая оценка 8.2, и авторы не берутся разрешать спор между двумя методологиями, замечая лишь, что обе попадают в высокий диапазон. Указанная в записи степень серьёзности «высокая» не зависит от того, какое число используется.

Одна CVE эксплуатировалась в реальных атаках; у инцидента с раскрытием ключа по умолчанию нет названного пострадавшего.

CISA добавила CVE-2026-59822 в каталог Known Exploited Vulnerabilities 2 сентября 2026 года и установила для федеральных гражданских ведомств крайний срок устранения — 16 сентября 2026 года; запись в каталоге содержит CWE-287 и CWE-306 — неправильная аутентификация и отсутствие аутентификации. В заметке Cloud Security Alliance сообщается, что отраслевые трекеры описали эту уязвимость как первую уязвимость, специфичную для MCP, в этом списке. Wiz опубликовала данные о наблюдаемой ею эксплуатации: с 7 июля 2026 года её ханипоты регистрировали запросы с односимвольными bearer-токенами, зондирующие конечные точки перечисления моделей, и Wiz не описывает никакого иного использования этой уязвимости.

Ничего сопоставимого для ключа по умолчанию не существует. Не названа ни одна жертва, ни один шлюз не указан как захваченный с помощью sk-1234, и никакая телеметрия не показывает использование 294 хостов. В записи архива не зафиксировано реального ущерба, что является утверждением о доказательствах, а не о механизме: подверженность была измерена, но не было засвидетельствовано её использование.

Ещё два случая часто относят к той же категории, хотя это не одно и то же. CVE-2026-42271 — выполнение команд через две тестовые конечные точки MCP — это уязвимость LiteLLM, которую злоумышленники действительно использовали для выполнения кода; ханипоты Wiz зафиксировали, что с её помощью устанавливался майнер криптовалют. Случай, опубликованный Microsoft в августе 2026 года, когда злоумышленник прочитал переменные среды контейнера шлюза, получил мастер-ключ, ключи провайдеров и строку подключения к базе данных, а затем скопировал записи из таблиц моделей и виртуальных ключей LiteLLM, иллюстрирует ценность скомпрометированного шлюза, а не новый способ проникновения; The Hacker News сообщает, что Microsoft оценивает точку входа как цепочку CVE-2026-42271.

Позиция мейнтейнеров состоит в том, что отсутствующий мастер-ключ — это ошибка настройки, а не уязвимость.

Политика безопасности LiteLLM недвусмысленна. Среди вопросов, выходящих за рамки, она перечисляет «атаки, требующие ошибки конфигурации при настройке (например, если master_key не задан в конфигурации прокси)», и указывает, что они явно не входят в область охвата и не считаются уязвимостями. Wiz приходит к совместимому выводу с другой стороны, когда называет поведение сквозной передачи (pass-through) вероятно работающим как задумано.

Эта позиция была проверена публично. 15 августа 2026 года исследователь открыл issue #37054 на GitHub, сообщив, что прокси с неустановленным LITELLM_MASTER_KEY аутентифицирует любое значение ключа и что поставляемый файл docker-compose его не задаёт. Issue был закрыт через 30 минут, и единственный комментарий к нему — с того же аккаунта: в нём цитируется указание из политики безопасности о том, что отчёты должны направляться через приватные отчёты об уязвимостях, а не через публичные issue, приносятся извинения за публичное создание issue и говорится, что полный отчёт вместо этого подаётся через канал advisory. На ветке не видно ответа мейнтейнера, так что в записи фиксируется отзыв публичного отчёта автором, а не ответ проекта на него. Ничто публичное не фиксирует, что стало с приватной заявкой.

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

Принудительные меры были приняты 3 октября, через двадцать четыре дня после сообщения.

Две ошибки в коде были исправлены задолго до отчёта. Хронология раскрытия Wiz фиксирует: выполнение кода в guardrail, о котором сообщили 18 февраля 2026 года и которое исправили 25 февраля в v1.82.0; обход MCP, исправленный 25 апреля в v1.84.0; эксплуатацию, замеченную 7 июля; публикацию идентификаторов CVE 8 июля и включение в каталог 2 сентября. Артефакты выпусков имеют более поздние даты, чем сами исправления: индекс пакетов показывает v1.82.0 от 1 марта 2026 года и v1.84.0 от 14 мая, что отмечает момент, когда каждое исправление стало доступно для установки, а не когда оно было внесено. Две записи о релизах от самой Wiz датируют те же исправления более поздним сроком, чем эта хронология. Релиз v1.82.0-stable на GitHub датирован 11 марта 2026 года, а пакет 1.82.0 на PyPI — 1 марта; v1.84.0 на обоих датирован 14 мая 2026 года. Ничто из опубликованного не объясняет этот разрыв, и для аргументации это не имеет значения, поскольку каждая из этих дат приходится на месяцы раньше сентябрьского отчёта. Два уведомления GitHub добавляют ещё третью дату: они были опубликованы 30 июня 2026 года — за три недели до идентификаторов CVE, которые, по словам Wiz, были выпущены 8 июля.

Ни один из этих выпусков не исправил значение по умолчанию. Wiz сообщила, что по состоянию на 9 сентября мастер-ключ по-прежнему устанавливался в значение sk-1234 при установке LiteLLM через Docker Compose или pip install, и The Hacker News подтвердило, что руководство по настройке в тот день всё ещё использовало это значение. Изменение появилось с версией v1.104.0, загруженной в Python Package Index 3 октября 2026 года; в примечаниях к её выпуску оно указано как ломающее изменение: теперь прокси отказывается запускаться, если мастер-ключ не задан, пуст или общеизвестен, указывая источник недопустимого значения в сообщении об ошибке при запуске и выводя команду, генерирующую безопасный ключ. Сопутствующая запись фиксирует изменение, которое прекращает публиковать общеизвестное слабое значение мастер-ключа в поставляемых конфигурациях и примерах, а файл docker-compose в основной ветке проекта больше вообще не задаёт ключ.

Вот эту последовательность стоит сохранить. Код был исправлен весной. Значение, из-за которого этих исправлений было недостаточно, оставалось в инструкции по установке вплоть до октября, и только тогда программное обеспечение начало его отвергать. Ни одно из двух исправлений не требовало, чтобы другое ждало.

Что не изменилось — так это сквозной маршрут к сервису метаданных экземпляра. Он по-прежнему не связан ни с CVE, ни с исправлением, поскольку проект считает администраторов доверенными. Поэтому список мер по устранению у Wiz — в основном работа оператора: надежный и уникальный мастер-ключ, проверка зарегистрированных guardrails с последующей перезагрузкой процесса для очистки кода, удерживаемого в памяти, аудит сквозных эндпоинтов с ограниченным исходящим трафиком контейнеров и роли IAM с минимальными привилегиями. Ни одна из этих четырех мер не достигается одним лишь обновлением.

Что не устанавливают материалы дела

• Независимого воспроизведения сканирования 3 074 хостов обнаружить не удалось. 9,6% — это измерение Wiz, и все прочие упоминания этой цифры воспроизводят её со ссылкой на источник.

• Актуальной цифры по подверженным экземплярам не существует. В ходе августовской последующей проверки было обнаружено более 85 000 экземпляров, которые, по словам Wiz, в основном являются ханипотами или тестовыми развертываниями и не могут сравниваться с февральским подсчётом.

• Ни одной жертвы. Ничто в записи не указывает на шлюз, оператора или облачную учётную запись, скомпрометированную через ключ по умолчанию, а эксплуатация, которую документирует Wiz, относится к обходу MCP, а не к sk-1234.

• Нет доказательств того, что эти 294 хоста использовались. Сканирование проверяло, пройдут ли они аутентификацию, а это более слабое утверждение, чем доказательство того, что кто-то это сделал.

• У уязвимости в guardrail нет устоявшейся оценки серьёзности. Wiz и сопровождающие описывают одно и то же поведение и оценивают его совершенно по-разному, а разница заключается в том, какие привилегии, по предположению каждой из сторон, у атакующего уже есть.

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

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