Пайплайн релизов LiteLLM взломали снова: инфостилер распространялся как v1.107.0 на PyPI и в Docker Hub
Утром 21 октября 2026 года на PyPI и в официальных Docker-образах проекта появилась вредоносная сборка LiteLLM. Версия 1.107.0 несла стилер учётных данных и загрузчик удалённого кода вместо того, что написали мейнтейнеры. Согласно собственному security-обновлению LiteLLM, был скомпрометирован сам пайплайн релизов — с использованием утекших учётных данных GitHub из аккаунтов разработчиков проекта. Вредоносные wheel-пакеты провели на PyPI меньше двух часов, а заражённые Docker-теги прожили весь день. В экосистеме автоматических сборок и зафиксированных зависимостей этого более чем достаточно, чтобы последствия оказались серьёзными.
Чистый тег, отравленная сборка
Раскрытие деталей читается как чек-лист того, насколько хрупко доверие к пакетам. LiteLLM сообщает, что злоумышленник получил OAuth-токены GitHub CLI из трёх аккаунтов разработчиков — судя по всему, они были записаны в логах открытого в интернет внутреннего деплоя LiteLLM; один из аккаунтов принадлежал владельцу организации на GitHub. С этими данными была снята защита веток, форсированно внесено изменение в workflow, а пайплайн направлен на репозиторий-двойник: Berri-AI/litellm — в одном дефисе от настоящего BerriAI/litellm. Официальный git-тег v1.107.0 остался чистым; вредоносные артефакты собирались из поддельного репозитория.«Эта версия содержала скомпилированную вредоносную программу, которая крадёт учётные данные и загружает инструменты удалённого исполнения кода». — из security-обновления LiteLLM, 21 октября 2026 годаОбнаружение, по крайней мере, было быстрым. Как сообщает BleepingComputer, охранные компании, включая Socket и Endor Labs, пометили релиз примерно за шесть минут, а PyPI удалил пакеты к 13:23 UTC; Docker Hub зачистили во второй половине дня. По словам LiteLLM, клиенты приватной корпоративной регистрации не пострадали. Но и шесть минут имеют значение, когда пакет набирает около 92 млн загрузок в месяц, а среди его пользователей значатся NVIDIA, Netflix и Okta — по данным BleepingComputer.
За чем охотится стилер
Механика полезной нагрузки объясняет категоричность рекомендаций. Wheel-пакеты сбрасывали три файла — cook.pth, cook.py и sitecustomize.py — в каталог site-packages Python. Python исполняет такие файлы при каждом запуске интерпретатора, поэтому вредонос выполнялся любым Python-процессом на машине, даже если LiteLLM ни разу не импортировался. Технический разбор Datadog Security Labs добавляет: удаление пакета litellm не убирает эти файлы — их приходится удалять вручную. Анализ инцидента от Kodem документирует, ради чего стилер создавался:- Облачные и инфраструктурные учётные данные: ключи AWS, Azure и GCP, включая токены метаданных инстансов, плюс секреты Kubernetes, Docker и Terraform
- ИИ-специфичный материал: API-ключи провайдеров LLM, учётные данные из базы прокси LiteLLM и файлы сессий ИИ-инструментов для программирования
- Токены разработчиков и реестров: учётные данные Git, токены GitHub, npm и PyPI, ключи SSH, GPG и TLS
- Локальные секреты: файлы .env, переменные окружения, история shell и баз данных
- Данные браузера: сохранённые пароли, cookie и записи автозаполнения
Второй инцидент с пайплайном за год
Это вторая скомпрометированная сборка LiteLLM в 2026 году. В марте атакующий, известный как TeamPCP, внедрил бэкдор в версии 1.82.7 и 1.82.8, взломав сканер Trivy в CI/CD-пайплайне проекта и украв токен PyPI. Datadog связывает две кампании только целью: связи между исполнителями не установлено. Неудобна сама схема — шлюз, стоящий в центре тысяч ИИ-стеков и хранящий ключи провайдеров и облачные учётные данные, за восемь месяцев дважды получил искажённый канал дистрибуции.Первый час по ранбуку
Kodem сопроводил индикаторы ранбуком реагирования на первый час, а рекомендация LiteLLM столь же категорична. Общий стержень:- Заблокировать litellm 1.107.0 на пакетном прокси, перестать развёртывать плавающие теги вроде latest и зафиксировать последнюю чистую версию 1.106.2 по хешу — образы по дайджесту
- Не запускать python и pip на затронутых хостах до очистки: каждый запуск интерпретатора снова исполняет нагрузку
- Изолировать хосты и контейнеры, затем вручную удалить cook.pth, cook.py, sitecustomize.py и их скомпилированные .pyc-файлы
- Ротировать с чистой машины: облачные роли, ключи провайдеров из базы прокси, master- и virtual-ключи LiteLLM, пароль базы данных, токены реестров и GitHub
- Проверить облачные журналы аудита на вызовы GetCallerIdentity и использование учётных данных с неожиданной инфраструктуры начиная с 11:39 UTC 21 октября