Произошла вещь, от которой у всех AI-разработчиков пробежал холодок по спине.

litellm — Python-библиотека для унифицированной работы с API разных LLM была отравлена.

Один pip install - и твои SSH-ключи, AWS/GCP/Azure креды, K8s Secrets, пароли от БД, криптокошельки, все API-ключи из .env — всё это упаковывается, шифруется через AES-256 и отправляется POST-запросом на поддельный домен http://models.litellm.cloud. Если обнаруживается среда K8s , то дополнительно разворачивается привилегированный Pod на каждом узле для латерального распространения.

Самое неприятное — способ активации. В пакет подложили файл litellm_init.pth размером 34 КБ. В Python .pth — это файлы конфигурации путей, которые автоматически обрабатываются модулем site при старте интерпретатора. Если строка начинается с import — она просто выполняется. Атака использует это поведение:

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

Тебе не нужно импортировать litellm и не нужно вызывать никакие функции. Запускаешь pip, python -c, IDE поднимает language server, или pytest гоняет тесты — достаточно старта Python-интерпретатора, и вредоносный код уже выполняется. Установил — значит уже скомпрометирован. Всё происходит незаметно

Пейлоад — трёхслойная base64-обфускация:

- первый слой (.pth) стартует подпроцесс
- второй — оркестратор с вшитым RSA-публичным ключом (4096 бит)
- третий — сборщик секретов, который вычищает /home, /opt, /srv, /var/www, /app, /data, /tmp

После сбора:

- генерируется случайный 32-байтовый AES-ключ
- данные шифруются
- ключ шифруется через RSA-OAEP
- всё пакуется в tpcp.tar.gz и уходит наружу

Помимо этого есть персистентный бэкдор:

- устанавливается как user-service systemd: ~/.config/sysmon/sysmon.py
- каждые 50 минут ходит на http://checkmarx.zone за командами
- скачивает в /tmp/pglog и исполняет
- стартует с задержкой 5 минут (обход песочниц)

Даже если удалить litellm, бэкдор остаётся.

pip install --require-hashes тоже не спасает — вредоносный файл легитимно прописан в RECORD, хэши совпадают, потому что пакет опубликован с украденного, но валидного PyPI-токена.

Даже если ты сам не ставил litellm, он тянется как зависимость в 2000+ пакетов (например, DSPy, MLflow, Open Interpreter и др.). По данным Mandiant, уже заражено 1000+ SaaS-окружений, прогноз — до 10 000.

Ирония в том, что атаку почти не обнаружили - её выдал баг у самих атакующих. .pth запускал подпроцесс, а тот при старте снова обрабатывал тот же .pth, вызывая рекурсивный запуск и фактически fork bomb. Это сожрало память у одного пользователя Cursor — так всё и вскрылось. Как отметил Karpathy: если бы код был чуть аккуратнее, атаку могли бы не замечать неделями.

Ещё абсурднее сама точка входа:

- 19 марта был скомпрометирован сканер безопасности Trivy
- через него группа TeamPCP украла PyPI-токен litellm
- 24 марта они выкатили заражённую версию

Инструмент безопасности стал вектором атаки.

После того как в GitHub создали issue:

- через 102 секунды атакующие с 73 взломанных аккаунтов наспамили 88 комментариев
- затем закрыли issue через скомпрометированный аккаунт мейнтейнера

Скрипт для самопроверки (версии, .pth, бэкдоры, сетевые соединения, K8s):
https://gist.github.com/sorrycc/30a765b9a82d0d8958e756b251828a19

Безопасная версия: litellm==1.82.6
Если у тебя стояли 1.82.7 или 1.82.8 — считай, что все креды утекли. Срочно ротируй всё. 🔨