СРОЧНО: LiteLLM скомпрометирован — бэкдор сливает ключи, SSH и креды Kubernetes
24 марта 2026 года на PyPI были опубликованы заражённые версии LiteLLM — популярного прокси для LLM-моделей. Бэкдор собирает SSH-ключи, облачные креды и секреты Kubernetes, а затем отправляет на сервер атакующих. Разбираю механику атаки и даю пошаговую инструкцию по защите.
Если вы используете LiteLLM — остановитесь и проверьте версию прямо сейчас. 24 марта 2026 года версии 1.82.7 и 1.82.8 были загружены на PyPI с вредоносным кодом. Это не теоретическая уязвимость — это активная атака на цепочку поставок, которая уже затронула тысячи разработчиков.
Что произошло
LiteLLM — популярный Python-пакет (40 000+ звёзд на GitHub), который работает как унифицированный прокси для обращения к моделям разных провайдеров: OpenAI, Anthropic, Google, Azure и других. Его используют в продакшене тысячи компаний.
24 марта группа атакующих TeamPCP опубликовала на PyPI две заражённые версии — 1.82.7 и 1.82.8. Соответствующих тегов в GitHub-репозитории нет: пакеты были залиты напрямую в PyPI, минуя стандартный релизный процесс.
Как они получили доступ? Через компрометацию Trivy — open-source сканера безопасности, который LiteLLM использовал в своём CI/CD-пайплайне. TeamPCP украли PyPI-креды мейнтейнера LiteLLM через заражённый Trivy и использовали их для публикации вредоносных версий.
Как работает бэкдор: три стадии атаки
Стадия 1: Сбор данных
Вредоносный код собирает с заражённой машины:
- SSH-ключи и конфигурации
- Файлы .env с секретами
- Креды AWS, GCP и Azure
- Конфиги Kubernetes (kubeconfig)
- Пароли баз данных
- .gitconfig и историю шелла
- Файлы криптокошельков
- Переменные окружения
- Данные из облачных metadata-эндпойнтов (IMDS)
Стадия 2: Эксфильтрация
Собранные данные шифруются с помощью вшитого RSA-ключа (4096 бит) через AES-256-CBC, упаковываются в tar-архив и отправляются POST-запросом на models.litellm.cloud — домен, не принадлежащий легитимной инфраструктуре LiteLLM.
Стадия 3: Латеральное движение и закрепление
Если на машине обнаружен токен Kubernetes service account, малварь создаёт привилегированные поды node-setup-* на каждой ноде в kube-system, монтирует хостовую файловую систему и устанавливает персистентный бэкдор через systemd-сервис. Бэкдор обращается к checkmarx.zone/raw каждые 50 минут за новыми инструкциями.
Ключевая деталь: .pth-файл запускается без импорта
В версии 1.82.7 вредоносный код внедрён в proxy_server.py — срабатывает при импорте модуля.
В 1.82.8 атакующие усилили вектор: добавили файл litellm_init.pth в корень пакета. Python автоматически исполняет .pth-файлы из site-packages при каждом запуске интерпретатора. Вам не нужно было даже импортировать LiteLLM — достаточно запустить любой Python-скрипт в виртуальном окружении, где установлен заражённый пакет.
Более того, .pth-лаунчер порождал дочерний процесс через subprocess.Popen, который снова триггерил тот же .pth — создавая экспоненциальный форк-бомб. Это, по иронии, баг в самой малвари, который и помог исследователям из FutureSearch обнаружить атаку.
Кто стоит за атакой
TeamPCP — группа, которая ранее скомпрометировала Trivy и KICS (инструменты безопасности от Checkmarx). Кампания затрагивает пять экосистем: GitHub Actions, Docker Hub, npm, Open VSX и PyPI.
«Эти компании создавались, чтобы защищать ваши цепочки поставок, но не могут защитить даже свои собственные. Мы уже сотрудничаем с другими командами, чтобы усилить хаос.»
Что делать прямо сейчас
1. Проверить версию
Запустите pip show litellm. Если версия 1.82.7 или 1.82.8 — вы затронуты.
2. Удалить заражённую версию и очистить кеш
pip uninstall litellm && pip cache purge (или rm -rf ~/.cache/uv для uv).
3. Откатиться на безопасную версию
pip install litellm==1.82.6
4. Проверить персистентность
Ищите: ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes — поды node-setup-* в kube-system.
5. Проверить сетевые логи
Ищите трафик на models.litellm.cloud и checkmarx.zone.
6. Ротировать ВСЕ креды
Если заражённая версия запускалась — считайте скомпрометированными SSH-ключи, AWS/GCP/Azure-токены, Kubernetes-конфиги, API-ключи из .env, пароли баз данных.
7. Аудит CI/CD
Проверьте, используются ли Trivy или KICS в пайплайнах. Если да — проведите аудит за период компрометации.
Масштаб проблемы
Заражённые версии были доступны на PyPI несколько часов. LiteLLM — транзитивная зависимость многих AI-фреймворков. Если вы используете MCP-плагины, AI-агентов или LLM-оркестраторы — проверьте, не подтянулся ли LiteLLM автоматически.
«Цепочка поставок open source схлопывается сама в себя. Trivy компрометируется → LiteLLM компрометируется → креды десятков тысяч окружений оказываются у атакующих → эти креды ведут к следующей компрометации. Мы в замкнутом круге.» — Гал Нагли, Wiz
Выводы
Эта атака — наглядная демонстрация того, что supply chain security в AI-экосистеме остаётся критически слабым звеном. Рекомендации:
- Пиньте зависимости. Используйте lock-файлы, а не диапазоны версий.
- Мониторьте аномалии. Форк-бомб при старте Python — не нормально. Логи процессов спасают.
- Используйте 2FA для PyPI. И не только для PyPI.
- Проверяйте соответствие тегов. Версия есть на PyPI, но нет тега в репо — красный флаг.
Заражённые версии уже удалены с PyPI. Если вы не обновлялись после 23 марта — вы в безопасности. Если обновлялись — действуйте немедленно.