Безопасность

СРОЧНО: LiteLLM скомпрометирован — бэкдор сливает ключи, SSH и креды Kubernetes

24 марта 2026 года на PyPI были опубликованы заражённые версии LiteLLM — популярного прокси для LLM-моделей. Бэкдор собирает SSH-ключи, облачные креды и секреты Kubernetes, а затем отправляет на сервер атакующих. Разбираю механику атаки и даю пошаговую инструкцию по защите.

28 марта 2026 г.
5 мин чтения
LiteLLMsupply chain attackPyPIбезопасностьAI-инфраструктураKubernetesTeamPCPTrivy

Если вы используете 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 марта — вы в безопасности. Если обновлялись — действуйте немедленно.

Автор: Алик Завалишев

Эксперт по ИИ и автоматизации процессов

Больше статей