Технический контекст
Я полез в разборы инцидента сразу, как увидел алерт, и картина там неприятная без всяких скидок. На PyPI скомпрометировали LiteLLM 1.82.7 и 1.82.8, причём вредоносный код был опубликован напрямую в реестр 24 марта 2026. По данным исследователей, это похоже на продолжение цепочки после взлома Trivy и кражи учёток из CI/CD.
Самое мерзкое — это не просто «плохой релиз». В 1.82.8 засунули .pth-файл, который исполняется при старте Python-процесса. То есть во многих сценариях вам даже не нужно явно импортировать LiteLLM, чтобы словить проблему.
Я отдельно зацепился за список того, что малварь вытаскивает с машины. Там SSH-ключи, .env, AWS/GCP/Azure credentials, Kubernetes-конфиги и service account токены, пароли от PostgreSQL, MySQL, Redis, MongoDB, shell history, Vault-токены, npm-токены, webhooks и вообще всё, что похоже на секреты. Если хост имел доступ к облаку или кластеру, считайте blast radius очень широким.
Дальше ещё веселее. Пакет не только уводит данные, но и пытается закрепиться в системе через sysmon.py, а в Kubernetes — читать secrets по namespace’ам и раскатывать привилегированные pod’ы по kube-system. Это уже не локальный инфостилер, а нормальная supply-chain атака с попыткой дальнейшего распространения.
Что делать прямо сейчас, если у вас где-то стоял LiteLLM 1.82.7 или 1.82.8:
- изолировать хосты и runner’ы, где пакет мог запускаться;
- снести уязвимые версии и почистить pip cache;
- искать litellm_init.pth, sysmon.py и подозрительные pod’ы в Kubernetes;
- ротировать все credentials без исключений;
- проверять исходящий трафик и логи после 24 марта.
И да, официальный совет «просто откатиться» тут недостаточен. Если пакет хоть раз исполнился, я бы исходил из предположения о полной компрометации секретов.
Влияние на бизнес и автоматизацию
Для меня это хороший, хоть и болезненный, пример того, что ИИ автоматизация ломается не только на качестве моделей и цене токенов. Она ломается на цепочке поставки. Один популярный пакет для LLM routing — и у вас под угрозой облако, CI/CD, база, Kubernetes и сервисные аккаунты.
Проигрывают команды, которые тащат зависимости в прод «как есть», без pinning, без изоляции runner’ов и без внятной схемы ротации секретов. Особенно больно будет тем, кто сделал внедрение ИИ быстро, но без нормальной AI-архитектуры: общий .env, длинноживущие ключи, широкий доступ у сервисов, один Kubernetes-кластер на всё подряд. В такой схеме одна библиотека превращается в проходной двор.
Выигрывают те, кто уже строит архитектуру ИИ-решений через короткоживущие credentials, segmented environments, workload identity и отдельные runner’ы под сборку. Да, это звучит менее весело, чем «подключили новый LLM-router за полчаса». Но именно так выглядит зрелая интеграция искусственного интеллекта, когда автоматизация с помощью ИИ не ставит под удар всю инфраструктуру.
Мы в Nahornyi AI Lab регулярно упираемся в это на практике: клиент хочет быстрое ИИ решение для бизнеса, а я первым делом лезу не в prompt’ы, а в секреты, сетевые политики и способ доставки зависимостей. Потому что внедрение искусственного интеллекта сегодня — это уже не только про модели. Это ещё и про то, насколько легко вашу LLM-обвязку можно превратить в точку входа.
Мой практический вывод простой: LiteLLM как инструмент сам по себе не «умер», но доверие к Python supply chain в AI-стеке снова получило по зубам. После такого я бы пересмотрел pinning, SBOM, подпись пакетов, правила для egress-трафика и права сервисных аккаунтов. И особенно — всё, что связано с Kubernetes и self-hosted runner’ами.
Этот разбор сделал я, Вадим Нагорный из Nahornyi AI Lab. Я занимаюсь ИИ автоматизацией руками: проектирую LLM-инфраструктуру, разбираю инциденты, собираю безопасные пайплайны и помогаю не превратить внедрение ИИ в источник новых дыр. Если хотите, я могу посмотреть ваш стек, оценить blast radius и вместе с командой Nahornyi AI Lab разобрать ваш конкретный кейс.