Это очень серьёзный инцидент из области безопасности — классический и крайне опасный пример атаки на цепочку поставок. Под удар попал популярнейший Python-пакет LiteLLM: у него более 40 тысяч звёзд на GitHub и около 97 миллионов загрузок в месяц. Для огромного числа проектов это не просто библиотека, а базовая зависимость.

Опасность в том, что речь идёт не об одиночной уязвимости, а о вредоносной версии пакета, которая могла попасть в самые разные среды разработки, CI/CD-пайплайны и серверы. Если заражённый пакет установлен у вас, под угрозой могут оказаться SSH-ключи, облачные креды, Kubernetes-конфиги, API-ключи, переменные окружения, история shell, пароли к базам данных и даже криптокошельки.

Известно, что вредоносный код содержался в версиях:

1.82.7

1.82.8

Если у вас установлен один из этих релизов, их нужно считать скомпрометированными.

По данным исследования, вредоносная нагрузка выполняла сразу несколько задач.

1. Сбор чувствительных данных

Скрипт пытался вытащить из системы:

SSH-ключи и конфигурации

.env-файлы

ключи AWS, GCP и Azure

Kubernetes-конфиги

git-учётные данные

историю команд shell

файлы криптокошельков

секреты CI/CD

пароли к базам данных

любые переменные окружения с секретами

2. Экcфильтрация данных

Собранная информация упаковывалась, шифровалась и отправлялась на внешний домен, не связанный с официальной инфраструктурой LiteLLM.

3. Попытки закрепиться в системе

Если окружение содержало Kubernetes-токены, вредоносный код пытался:

читать секреты во всех namespace;

создавать привилегированные Pod’ы;

размещать persistent backdoor;

закрепляться как в локальной системе, так и в контейнерной среде.

Karpathy справедливо назвал подобные атаки одними из самых страшных в современном ПО. Причина проста: сегодня разработчики ставят десятки и сотни зависимостей, а одна из них может оказаться заражённой.

Особенно страшно то, что одна скомпрометированная машина может стать источником следующей волны заражения: украденные ключи можно использовать для доступа к другим системам, а затем — для новой компрометации пакетов и аккаунтов.

Это уже не просто баг, а механизм самораспространяющейся компрометации.

Иронично, но вредоносный код выдал сам себя из-за ошибки в реализации. Один из разработчиков обнаружил проблему, когда пакет подтянулся как транзитивная зависимость в среде Cursor/MCP.

Из-за особенностей запуска .pth-файла процесс начал порождать самого себя снова и снова, что в итоге привело к взрывному росту числа процессов и падению машины. То есть вредоносный код оказался не только злонамеренным, но и плохо написанным.

По данным отчётов, атака не шла через обычный GitHub workflow. Вместо этого злоумышленник использовал украденный PyPI-токен и загрузил поддельную версию пакета напрямую в PyPI.

Это важный момент: GitHub-репозиторий при этом оставался чистым. То есть проблема была не в исходниках на GitHub, а в компрометации механизма публикации.

Если вы использовали LiteLLM в последние дни, особенно после 24 марта 2026 года, стоит немедленно сделать следующее:

1. Проверить, не установлена ли заражённая версия

Проверьте пакет командой:

pip show litellm

Также стоит проверить кэш uv и виртуальные окружения в CI/CD.

2. Удалить пакет и очистить кэш

Если обнаружена заражённая версия, её нужно удалить и обязательно очистить локальный кэш менеджера пакетов, чтобы вредоносный wheel не был установлен повторно.

3. Проверить следы закрепления

Нужно искать такие артефакты, как:

~/.config/sysmon/sysmon.py

~/.config/systemd/user/sysmon.service

Если используются Kubernetes-кластеры, следует проверить namespace kube-system на наличие подозрительных Pod’ов и убедиться, что secrets не были скомпрометированы.

4. Срочно сменить все возможные секреты

Это самый важный шаг. Считайте, что если машина была затронута, то все ключи и пароли могли утечь. Нужно немедленно ротировать:

SSH-ключи

облачные ключи AWS/GCP/Azure

Kubernetes-конфиги

API-ключи из .env

пароли к базам данных

История с LiteLLM — это напоминание, что в современном Python- и AI-стеке опасность часто приходит не из основного кода, а из цепочки зависимостей.

Мы привыкли доверять пакетам, которые ставим через pip install, но эта привычка всё чаще становится слабым местом. Чем больше зависимостей, тем шире поверхность атаки. А в эпоху AI и облаков цена ошибки особенно высока.

Если у вас есть хоть малейшее отношение к Python-разработке, ML-инфраструктуре, DevOps или CI/CD — проверьте свои окружения прямо сейчас.