LiteLLM скомпрометировали через PyPI: вредоносные версии крали ключи, токены и пароли

24 марта 2026 года команда LiteLLM сообщила о предполагаемой атаке на цепочку поставок (supply chain attack): в PyPI опубликованы две вредоносные версии пакета litellm — 1.82.7 и 1.82.8. Эти версии уже удалили из PyPI, но разработчики предупреждают: если они успели попасть в окружение, все секреты на затронутой машине нужно считать скомпрометированными.

LiteLLM — это популярная open-source-библиотека и AI Gateway, которая предоставляет единый интерфейс для работы с более чем 100 LLM-провайдерами в формате OpenAI API. Проще говоря, её используют как прослойку между приложением и моделями OpenAI, Anthropic, Vertex AI, Bedrock и другими. 

По официальному сообщению LiteLLM, затронуты версии litellm==1.82.7 и litellm==1.82.8. Команда пишет, что одна из версий содержала вредоносную нагрузку в proxy_server.py, а другая — ещё и файл litellm_init.pth, который выступает как дополнительный индикатор компрометации. Обе версии уже убрали из PyPI.

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

Разработчики отдельно пишут, что инцидент возможно связан с более широкой компрометацией Trivy, затронувшей CI/CD-цепочки и доверенные каналы дистрибуции. Aqua Security указывает, что 19 марта 2026 года атакующий действительно использовал скомпрометированные учётные данные для публикации вредоносных артефактов Trivy, а Microsoft позже выпустила отдельные рекомендации по обнаружению и расследованию этой цепочки атак.

Согласно официальному отчёту LiteLLM, вредоносная нагрузка рассчитана на сбор секретов. Команда перечисляет среди целей переменные окружения, SSH-ключи, облачные учётные данные AWS, GCP и Azure, Kubernetes-токены, пароли к базам данных.

Дальше собранные данные шифровали и отправляли POST-запросом на домен models.litellm.cloud, который команда прямо называет неофициальным и не связанным с BerriAI / LiteLLM. 

BleepingComputer также сообщил, что атака затронула именно вредоносные PyPI-релизов LiteLLM и стала частью более широкой кампании, которую ряд исследователей связывает с TeamPCP. Но в официальном посте LiteLLM пока не называют злоумышленника.

Команда LiteLLM даёт довольно чёткое окно времени, когда существовал риск. По их данным, под удар могли попасть пользователи, которые:

• устанавливали или обновляли LiteLLM через pip 24 марта 2026 года между 10:39 UTC и 16:00 UTC;

• запускали pip install litellm без фиксации версии;

• собирали Docker-образы в это окно времени;

• получили LiteLLM как транзитивную зависимость — то есть не ставили пакет напрямую, но он подтянулся через другой инструмент, например агентный фреймворк, MCP-сервер или инструмент оркестрации LLM.

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

LiteLLM отдельно перечислила, кого проблема не должна была затронуть:

• пользователей LiteLLM Cloud;

• тех, кто использует официальный Docker-образ LiteLLM Proxy: ghcr.io/berriai/litellm;

• пользователей, оставшихся на версии 1.82.6 или ниже;

• тех, кто устанавливал LiteLLM из исходников с GitHub, а не из PyPI.

Команда также сообщила, что официальный LiteLLM Proxy image не зависел от вредоносных PyPI-публикаций, потому что путь развёртывания там опирается на requirements.txt с зафиксированными зависимостями.

LiteLLM советует первым делом проверить установленную версию пакета через pip show litellm и отдельно искать файл litellm_init.pth в каталоге site-packages. Команда приводит пример команды для поиска этого файла и называет его важным IoC. Ещё один признак — исходящие обращения к models.litellm.cloud.

Администраторам рекомендуют выполнить три шага:

1. проверить, не установлены ли версии 1.82.7 или 1.82.8;

2. проверить файловую систему на litellm_init.pth;

3. просмотреть сетевые логи, прокси-логи, EDR и DNS-логи на обращения к models.litellm.cloud.

Если хотя бы один из этих признаков обнаружен, инцидент уже не стоит рассматривать как «возможный»: нужно переходить к режиму реагирования.

Официальная рекомендация LiteLLM: считать все секреты на затронутой системе скомпрометированными и немедленно их ротировать. Это касается API-ключей, облачных ключей, паролей к БД, SSH-ключей, Kubernetes-токенов и любых секретов из переменных окружения или конфигурационных файлов.

Кроме ротации секретов команда советует:

• удалить найденный litellm_init.pth;

• провести расследование хоста на предмет дальнейшей компрометации;

• сохранить артефакты, если инцидентом занимается команда безопасности;

• проверить локальные окружения, CI/CD, Docker-сборки и deployment-логи;

• временно зафиксировать версию LiteLLM 1.82.6 или ниже, либо перейти на более поздний проверенный релиз, когда его выкатят и объявят безопасным.

Простое удаление пакета проблему не решает, если злоумышленник уже успел украсть ключи. В supply-chain-инцидентах основной риск несёт не сам вредоносный файл, а утечка секретов, через которые можно продолжить атаку уже в облаке, в Kubernetes, в GitHub Actions, в базах данных и в сервисных аккаунтах.

LiteLLM сообщает, что уже:

• удалила скомпрометированные версии из PyPI;

• провела ротацию учётных данных мейнтейнеров;

• назначила новых авторизованных мейнтейнеров;

• привлекла команду Google Mandiant для форензики цепочки сборки и публикации;

• приостановила выпуск новых релизов до завершения более широкого аудита цепочки поставки.