В релизе LiteLLM 1.107.0 обнаружены инфостилер и бэкдор

21 октября 2026 года релизный конвейер LiteLLM был скомпрометирован. В течение нескольких часов в PyPI, Docker Hub и GitHub Container Registry (GHCR) распространялась версия 1.107.0 с инфостилером и бэкдором. Проект удалил вредоносные артефакты и опубликовал разбор атаки ^[1]. Об инциденте также писал «Хакер» ^[2], а на Хабре ^[3] уже выходили материалы с техническим разбором атаки и механизма запуска вредоноса. Наш материал — короткий обзор для операторов и пользователей ИИ-шлюзов: что произошло, чем это грозит и какие действия нужно предпринять, если 1.107.0 запускалась. Ниже основные факты, возможные последствия для пользователей ИИ-шлюзов и короткие рекомендации.

Что произошло

LiteLLM — это открытый Python SDK и ИИ-шлюз, через который приложения обращаются к моделям разных поставщиков по единому API. Это один из самых популярных ИИ-шлюзов: по данным проекта на начало октября, LiteLLM скачивают около 90 млн раз в месяц, а на GitHub у него более 60 тыс. звезд.

В PyPI зараженный пакет провисел с 14:39 до 16:23 МСК. В Docker Hub теги v1.107.0, latest, main-latest и main-stable указывали на зараженный образ с 14:46 до 17:20, в GHCR с 14:46 до 16:51. Затронуты все семь wheel-пакетов, а также образы litellm, litellm-database и litellm-non_root в GHCR.

Атакующие не меняли исходный код LiteLLM в официальном репозитории GitHub: тег v1.107.0 там чистый. Они вмешались в процесс публикации и перенаправили сборку в похожий репозиторий Berri-AI/litellm, который отличался от настоящего BerriAI/litellm одним дефисом. В результате вредоносный пакет собрали и подписали, не трогая официальный код. То есть чистый код на GitHub еще не гарантирует чистый пакет.

При этом приватный реестр LiteLLM не затронут: по данным проекта ^[1], enterprise-клиенты, которые берут пакеты оттуда, не пострадали.

Это не первый инцидент

24 марта 2026 года в PyPI уже публиковались вредоносные версии 1.82.7 и 1.82.8. В 1.82.7 код добавили в proxy_server.py, и он срабатывал при импорте. В 1.82.8 появился файл litellm_init.pth, который запускал полезную нагрузку при каждом старте Python. По разным оценкам, пакеты были доступны от 40 минут до 2,5 часов: LiteLLM говорил примерно о 40 минутах ^[4], PyPI сообщал о 2 часах 32 минутах ^[5].

Полезная нагрузка собирала SSH-ключи, облачные учетные данные, токены Kubernetes, секреты CI/CD и .env. Данные шифровались и уходили на models.litellm.cloud ^[6]. Отдельно вредонос пытался закрепиться в кластерах Kubernetes через привилегированные поды. Последней чистой версией тогда считалась 1.82.6, чистая 1.83.0 вышла 30 марта 2026 года. Инцидент связывают с группировкой TeamPCP ^[7], а входной точкой считают скомпрометированный GitHub Action aquasecurity/trivy-action ^[8]; эта связь не подтверждена полностью.

Как работал вредонос на этот раз

Socket пишет ^[9], что в пакеты добавили три файла: cook.pth, cook.py и sitecustomize.py. Они используют штатные механизмы запуска Python. cook.pth импортировал cook.py, который запускал стилер privcollect. Модуль sitecustomize.py, по данным The Hacker News ^[10], работал только на Linux и macOS и запускал фоновый загрузчик для удаленного выполнения кода.

Вредонос активировался при любом запуске Python в зараженном окружении, включая запуск pip. В разборах Security Boulevard ^[11] и GMO Flatt ^[12] стилер собирал облачные ключи AWS, Azure и Google Cloud, доступы к Kubernetes и Docker, токены GitHub, npm и PyPI, SSH-, GPG- и TLS-ключи, файлы .env, данные браузеров и токены AI-инструментов, включая Cursor и GitHub Copilot. CERT-In отдельно отмечает ^[13] переменные окружения, секреты CI/CD и токены репозиториев. Данные отправлялись на litellm.dev/healthcheck ^[14]. Загрузчик раз в час обращался к GitHub-репозиторию letters9813/pythonclient-test, читал domain.txt с адресом управляющего сервера и скачивал скрипт с /codepy.

Как злоумышленники получили доступ к релизу

По хронологии атаки от LiteLLM ^[15], мастер-ключ LiteLLM Agent Platform утек в публичный репозиторий LiteLLM-Labs/lite-harness 27 мая 2026 года. Коммит с конфигурационным файлом переписали, однако сам ключ так и не отозвали. 10 октября злоумышленники использовали его для доступа к платформе. Они получили GitHub CLI OAuth-токен владельца организации, а затем токены двух мейнтейнеров.

Сборку перенаправили на похожий репозиторий Berri-AI/litellm, обошли защиту ветки и выпустили пакет через штатный конвейер. Вредоносные артефакты прошли подпись и были опубликованы как официальный релиз. Проект временно ослабил процедуру согласования релизов, и атакующие этим воспользовались.

Возможные последствия

Похищенные облачные ключи дают доступ к инфраструктуре. Wiz ^[16] зафиксировала: через 4,5 часа после утечки ключи AWS проверяли через sts:GetCallerIdentity, а затем смотрели модели Bedrock. Это похоже на LLMjacking. С ключами провайдеров ИИ можно тратить бюджет жертвы на модели, с токенами CI/CD и репозиториев можно повторить атаку от имени доверенного проекта. SSH-, GPG- и TLS-ключи, данные браузеров и сессии открывают путь вглубь инфраструктуры, загрузчик дает произвольный код, а внутренние зеркала и кеши могут разнести зараженную версию по командам.

Что делать

Сначала проверьте, использовалась ли версия 1.107.0 и затронутые теги. Смотрите pip show litellm, lock-файлы, SBOM, локальные кеши, внутренние зеркала, образы и дайджесты, CI-раннеры и рабочие машины разработчиков.

Если версия запускалась, не запускайте Python и pip в этом окружении. Удалите cook.pth, cook.py, sitecustomize.py и соответствующие файлы __pycache__ , остановите процесс, держащий /tmp/remote_code_loader.lock, и пересоберите окружение или образ с нуля на версии 1.106.2. При наличии исходящего интернета считайте данные скомпрометированными. С чистого хоста отзовите и смените облачные ключи и роли, секреты Kubernetes и Docker, токены GitHub, npm и PyPI, SSH-, GPG- и TLS-ключи, данные .env, ключи провайдеров ИИ, master и virtual keys LiteLLM, пароль DATABASE_URL. Затем проверьте следы: обращения к litellm.dev ^[17], репозиторию letters9813/pythonclient-test и путям /codepy, файлы-маркеры, переменную PRIVCOLLECT_ACTIVE=1, процесс с рабочим каталогом /. Удалите затронутые артефакты из внутренних зеркал, реестров и кешей.

Для профилактики зафиксируйте LiteLLM и зависимости на конкретных версиях и хешах, не тяните latest в прод. Поставьте внутреннее зеркало пакетов с задержкой или карантином и проверяйте подписи, provenance и SBOM. В CI и на раннерах не храните долгоживущие облачные ключи. Используйте короткоживущие токены с минимальными правами, включите сканирование секретов с автоотзывом и фильтрацию исходящего трафика.

Автор:

Алексей Синадский, к.т.н., ведущий исследователь ИЦ УЦСБ