CISA добавляет в KEV обход аутентификации MCP в LiteLLM: достаточно было любого Bearer-токена

2 сентября 2026 года Агентство по кибербезопасности и защите инфраструктуры США добавило CVE-2026-59822 в каталог известных эксплуатируемых уязвимостей как «Уязвимость ненадлежащей аутентификации BerriAI LiteLLM» — одну из семи уязвимостей в партии за тот день. Ошибка находится в конечной точке MCP Streamable HTTP в LiteLLM: когда проверка ключа LiteLLM завершалась неудачей, запасной механизм сквозной передачи OAuth2 подставлял пустой объект UserAPIKeyAuth() вместо отклонения запроса, поэтому любой поддельный заголовок Authorization Bearer открывал аутентифицированный сеанс MCP. Злоумышленник, достигший этой конечной точки, мог перечислить и вызвать все инструменты MCP, настроенные для шлюза, и через эти инструменты получить доступ к сервисам за ними. Затронуты все версии до 1.84.0, а федеральным гражданским ведомствам было дано время до 16 сентября на устранение уязвимости. Эта запись — позиция в KEV об обходе аутентификации MCP в LiteLLM — является одной из записей в OrcaRouter AI Incident Archive, где хранится полный набор записей и соседние записи этого инцидента.

Причина, по которой ошибка в прокси важнее, чем можно судить по её оценке CVSS, заключается в том, что стоит за прокси. Команда исследования угроз Wiz формулирует это прямо: «Прокси LiteLLM может хранить ключи для каждого провайдера моделей, на который он маршрутизирует запросы, включая OpenAI, Anthropic, Azure и Gemini. Он также может работать с разрешениями облачного IAM и подключаться к внутренним сервисам через серверы инструментов MCP. Единственная компрометация может дать злоумышленнику доступ к учётным данным и сервисам, находящимся ниже по потоку от прокси, а не только к самому прокси». Wiz Research сообщает, что обнаружила эту уязвимость, а позже ханипоты Wiz зафиксировали попытки её использовать.

Механизм: неудачная проверка, вернувшая действительную сессию

Собственный бюллетень BerriAI GHSA-7488-6r32-c95q описывает дефект в двух предложениях: «Обработчик аутентификации MCP поддерживал сквозную передачу OAuth2 для вышестоящих MCP-серверов, но резервный путь мог заменить неудачную проверку ключа LiteLLM пустым объектом UserAPIKeyAuth(). Это позволяло запросам с поддельным заголовком Authorization достигать инструментов MCP без действительного ключа LiteLLM». Важное слово — fallback. В коде была ветка для развёртываний, которые передают OAuth-токен вышестоящего MCP-сервера напрямую, и когда ключ LiteLLM не проходил проверку, эта ветка возвращала пустой объект аутентификации вместо ошибки.

Пустой объект аутентификации — это не то же самое, что отсутствие объекта аутентификации. Код ниже по потоку видел успешно созданный UserAPIKeyAuth и продолжал выполнение, хотя к нему не были привязаны ни тенант, ни пользователь, ни область действия. В публикации Wiz о практическом последствии сказано более прямо: «когда проверка токена не проходит, вместо отклонения запроса сервер возвращает пустой объект UserAPIKeyAuth() без каких-либо ограничений. Любой Bearer-токен (даже один символ, например x) предоставляет полный доступ к MCP».

То, что это даёт атакующему, — это меню. Протокол MCP раскрывает перечень инструментов, поэтому аутентифицированная сессия возвращает имена и схемы каждого инструмента, к которому шлюз был настроен иметь доступ, — баз данных, репозиториев кода, внутренних API, как в примерах Wiz. В рекомендациях производителя эффект описан прямо: «Атакующий может использовать это для перечисления и вызова настроенных инструментов MCP и доступа к подключённым сервисам, предоставляемым через MCP». Затем вызовы инструментов выполняются с теми правами, которыми сам прокси обладает в отношении этих бэкендов, что и является проблемой концентрации учётных данных, описанной Wiz.

Исправление в мае, CVE в июле, федеральный дедлайн в сентябре

Даты не выстраиваются так, как мог бы предположить читатель, и самое интересное — это промежутки между ними. LiteLLM 1.84.0 — первая версия, которую уведомление называет исправленной, — была загружена на PyPI 14 мая 2026 года, согласно собственным метаданным релиза в индексе пакетов. Идентификатор CVE был зарезервирован в программе CVE 7 июля 2026 года, а запись опубликована на следующий день, 8 июля; запись OSV PYSEC-2026-3479 появилась 23 июля. Включение в KEV последовало 2 сентября с крайним сроком устранения 16 сентября.

Из этого следуют две вещи. Во-первых, пропатченная сборка была общедоступна более трёх месяцев до того, как CISA внесла уязвимость в список эксплуатируемых — то есть у организаций, на которые распространялся срок, всё это время было доступно рабочее обновление, и включение в KEV не было моментом появления исправления. Во-вторых, с тех пор разрыв в версиях только увеличился: текущий релиз LiteLLM на PyPI — 1.106.5, загруженный 27 октября 2026 года. Развёртывание, которое до сих пор остаётся на любой версии ниже 1.84.0, теперь отстаёт более чем на двадцать минорных релизов, а не просто на один патч.

Что устанавливает листинг, а что — нет

В уведомлении CISA о пакете говорится, что дополнения внесены «на основании свидетельств активной эксплуатации», а машиночитаемая запись каталога для CVE-2026-59822 содержит дату добавления 2 сентября 2026 года, крайний срок 16 сентября 2026 года, значение параметра known-ransomware-campaign-use — «Unknown» — и две слабости: CWE-287 (ненадлежащая аутентификация) и CWE-306 (отсутствие аутентификации для критически важной функции).

• Установлено: CISA оценила уязвимость как активно эксплуатируемую и включила её в федеральный перечень для устранения. В записи SSVC от NVD, приписываемой координатору CISA и датированной 2 сентября 2026 года, эксплуатация указана как "active", автоматизируемость — как "yes", а техническое воздействие — как "partial".

• Установлено:эксплуатация наблюдалась в контролируемой среде. Wiz опубликовала трафик ханипотов, показывающий запросы с токенами из одного символа, которые проверяли эндпоинт перечисления моделей: GET к /v1/models с заголовком "Authorization: Bearer x". The Hacker News, сообщая 3 сентября о партии KEV, описало ту же активность как наблюдение Wiz за «попытками эксплуатации с участием CVE-2026-59822 против своих ханипотов для проверки эндпоинтов перечисления моделей».

• Установлено:оба показателя серьёзности существуют и различаются в зависимости от фреймворка. В бюллетене BerriAI уязвимости присвоен рейтинг CVSS 4.0 — 8,8 (высокий), при этом конфиденциальность — высокая, целостность — низкая, доступность — отсутствует; собственная оценка NIST по CVSS 3.1, которая является основной в NVD, оценивает её в 8,2. Эти два числа описывают один и тот же дефект в разных системах оценки, и их не следует сравнивать так, будто одно заменило другое.

• Не установлено: ни одна конкретная жертва не названа. Ни предупреждение CISA, ни рекомендация BerriAI, ни отчёт Wiz, ни материал The Hacker News не называют организацию, чьи инструменты MCP были доступны через эту уязвимость, и не сообщают об учётных данных или данных, похищенных у неё. Публичная информация об эксплуатации — это телеметрия ханипотов и федеральное заключение, а не раскрытая утечка.

• Не установлено: что ни одна группировка программ-вымогателей его не использует. В поле KEV указано «Unknown» — это значение, которое присваивает CISA, а не вывод об отсутствии в любом случае.

Июньский прецедент — и цепочка удалённого выполнения кода, которой это не является

Это вторая уязвимость LiteLLM, попавшая в каталог KEV в 2026 году, и её легко спутать с предыдущей. CVE-2026-42271, добавленная 8 июня 2026 года со сроком устранения до 22 июня, представляет собой внедрение команд в тестовых эндпоинтах MCP-сервера LiteLLM: Wiz описывает эндпоинты, позволяющие пользователю протестировать конфигурацию MCP-сервера перед сохранением, при этом поле command передаётся на выполнение в subprocess без проверки. Злоумышленники отправляли поддельную конфигурацию stdio-сервера, команда которой загружала и запускала криптомайнер, и возвращали правдоподобное рукопожатие MCP, чтобы тест выглядел успешным. В записи CISA для неё указаны CWE-78 и CWE-77 — внедрение команд и аргументов, а не аутентификация.

Этот недостаток — тот самый, который выстраивается в цепочку. Wiz заявляет, что CVE-2026-42271 «может быть объединён в цепочку с обходом проверки заголовка Host в Starlette (CVE-2026-48710), что позволяет добиться полностью неаутентифицированного RCE», и что внешние исследователи связали группу вымогателей Qilin с активной эксплуатацией этой цепочки. CVE-2026-48710 была добавлена в каталог KEV в том же пакете от 2 сентября, что и обход LiteLLM, с тем же крайним сроком 16 сентября, а собственная заметка CISA в каталоге по недостатку Starlette гласит, что он может быть объединён в цепочку с CVE-2026-42271. Связь с Qilin относится именно к этой паре. Это не вывод о CVE-2026-59822, и ничто в рассмотренных источниках не связывает группу вымогателей с обходом аутентификации.

Одна административная деталь отличает две записи LiteLLM: в требуемом действии июньского перечня указана BOD 22-01, более старая обязательная операционная директива, тогда как в сентябрьском перечне указана BOD 26-04, «Prioritizing Security Updates Based on Risk». В предупреждении CISA это изменение не объясняется, и в каталоге оно не аннотируется.

Что изменилось после

Путь к устранению уязвимости недолог. В рекомендациях BerriAI предлагается обновиться до версии 1.84.0 или более поздней, а также приводится обходной путь для команд, которые не могут перейти немедленно: «отключите маршруты MCP или заблокируйте доступ к /mcp/ и связанным конечным точкам MCP на вашем обратном прокси или шлюзе API». Этот обходной путь — грубый инструмент: он удаляет возможность, а не ограничивает доступ к ней, — но это единственное средство смягчения, которое поставщик называет для неисправленных развертываний.

Текст CISA об обязательных действиях для точек входа ставит федеральные агентства перед тем же компромиссом: применить меры защиты согласно инструкциям поставщика и в соответствии с BOD 26-04 «или прекратить использование продукта, если меры защиты недоступны», при этом каждое агентство отвечает за оценку подверженности актива воздействию из интернета. Директива обязательна только для федеральных гражданских агентств исполнительной ветви власти; CISA призывает другие организации применять ту же приоритизацию на основе рисков, не требуя этого.

Публично не известно, предпринял ли кто-либо за пределами ханипота какие-либо действия к установленному сроку. Ни CISA, ни BerriAI не опубликовали данные о том, сколько развертываний LiteLLM было подвержено воздействию, сколько было исправлено до 16 сентября и сколько было затронуто через обходной путь.

Что остаётся открытым

Три пробела стоит назвать прямо, а не обходить молчанием. Нет публичного отчёта об инциденте, связывающего CVE-2026-59822 с конкретным вторжением, поэтому включение в KEV опирается на свидетельства эксплуатации от CISA и наблюдения Wiz за ханипотами, а не на документально подтверждённую жертву. Нет заявления поставщика о том, как резервный путь оказался написан именно так или как долго он существовал до 1.84.0 — в рекомендации описываются дефект и его исправление, а не его история. И сроки в этой партии были неодинаковыми: пять из семи записей, добавленных 2 сентября, имели крайний срок 5 сентября, тогда как записи LiteLLM и Starlette — 16 сентября. CISA не объясняет почему.

То, что установлено, уже и полезнее, чем оценка. Один-единственный символ в заголовке Authorization на затронутых версиях был неотличим для конечной точки MCP от действительного ключа — а версии, которые вели себя так, перестали быть актуальными в мае 2026 года.