LiteLLM 1.107.0: скомпрометированный релиз в PyPI и Docker читал файлы с учётными данными

Коротко: 21 октября 2026 года атакующие скомпрометировали аккаунты трёх инженеров LiteLLM через украденные GitHub CLI OAuth-токены и опубликовали вредоносную версию 1.107.0 в PyPI (11:39–13:23 UTC) и Docker Hub (11:46–14:20 UTC). Код прятался в стартовых файлах Python и запускался при каждом запуске интерпретатора — даже если приложение само LiteLLM не импортировало. Он читал файлы service account Kubernetes, конфиг Docker, ключи AWS/Google Cloud, SSH/GPG-ключи и файлы авторизации Claude Code, Codex, Gemini CLI и Cursor, отправляя их на сервер атакующих. Это уже второй подобный инцидент с LiteLLM за год — в марте 2026-м похожая атака привела к утечке данных около 2500 компаний.

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

LiteLLM — популярная open-source библиотека и прокси-сервер, который даёт разработчикам единый API для вызова моделей OpenAI, Anthropic, Google и десятков других провайдеров. Проект активно используют AI-стартапы и внутренние команды крупных компаний для маршрутизации запросов к разным LLM.

21 октября 2026 года в 04:00 PST в PyPI и официальные Docker-образы LiteLLM была опубликована версия 1.107.0, содержащая скомпилированный вредоносный модуль. Пакет находился в открытом доступе около двух часов: в PyPI — с 11:39 до 13:23 UTC, в Docker-реестрах — с 11:46 до 14:20 UTC, после чего команда LiteLLM удалила скомпрометированные релизы.

Как вредоносный код попал в официальный релиз

Это не классическая атака на цепочку поставок через подставной клон пакета — злоумышленники получили доступ к самому легитимному релизному процессу проекта:

1. Начальный доступ. По предположению команды LiteLLM, атакующие воспользовались недавно устранённой уязвимостью, чтобы получить доступ к внутреннему развёртыванию, открытому в интернет, и извлечь токены из логов.
2. Кража OAuth-токенов. С помощью этого доступа злоумышленники похитили GitHub CLI OAuth-токены сразу трёх инженеров проекта.
3. Модификация релизного пайплайна. Используя эти токены, атакующие изменили процесс сборки и одобрили публикацию вредоносного релиза от имени легитимных разработчиков.
4. Заметание следов. После публикации записи о соответствующих workflow в CI были удалены, чтобы затруднить расследование.

Какие файлы на диске читает вредоносный код

Ключевая техническая деталь инцидента — вредоносный код был размещён в стартовых файлах Python, которые интерпретатор исполняет автоматически при каждом запуске. Это значит, что заражение активировалось даже в тех приложениях, которые LiteLLM вообще не импортировали — достаточно было, чтобы заражённый пакет присутствовал в окружении.

После запуска стилер собирал и пытался выгрузить на сервер атакующих содержимое следующих категорий файлов:

• Облачные учётные данные — файлы service account Kubernetes, конфигурационные файлы Docker, смонтированные секреты, а также credentials, полученные через metadata-сервисы AWS и Google Cloud.
• AI-токены — файлы авторизации инструментов Claude Code, Codex, Gemini CLI и Cursor, а также ключи API самих провайдеров LLM и конфигурации моделей LiteLLM.
• Секреты разработчика — SSH- и GPG-ключи, токены Git, GitHub, npm и систем CI/CD.
• Браузерные данные — сохранённые логины, куки и история браузера.
• Прочие окружения — на Linux-системах код дополнительно читал переменные окружения других процессов, доступных для чтения.

Такой набор целей — это не случайный сбор данных, а прицельная охота за файлами, которые дают доступ к инфраструктуре целиком: от облачного аккаунта компании до API-ключей для AI-сервисов. Если вы разбираете, какие расширения файлов потенциально опасны для хранения в открытом виде, см. наш материал «Карта опасных расширений файлов».

Второй подобный инцидент за год

Это уже не первая компрометация цепочки поставок LiteLLM в 2026 году. В марте 2026-го похожая атака на релизный пайплайн привела к публикации вредоносных версий 1.82.7 и 1.82.8 и утечке архива объёмом около 153 ГБ, который, по оценкам исследователей, затронул данные примерно 2500 корпоративных доменов, включая крупные технологические и промышленные компании.

Повторный инцидент показывает системную проблему: даже после первой атаки защита релизного пайплайна (хранение и ротация OAuth-токенов разработчиков, мониторинг внутренних сервисов, открытых в интернет) осталась недостаточной, чтобы предотвратить вторую компрометацию тем же вектором — украденными токенами доступа.

Что делать, если вы использовали LiteLLM 1.107.0

Команда LiteLLM подтвердила, что все версии, кроме скомпрометированной 1.107.0, безопасны, а заражённые релизы удалены из PyPI и Docker-реестров. Если в вашем окружении в период с 21 по 22 октября 2026 года устанавливалась или обновлялась эта версия, рекомендуется:

1. Обновиться до безопасной версии — например, 1.106.2 или более новой, не затронутой инцидентом.
2. Считать все потенциально доступные вредоносному коду секреты скомпрометированными. Исследователи безопасности прямо советуют ротировать учётные данные, даже если прямых признаков их использования пока не видно.
3. Ротировать ключи AWS, Google Cloud и Azure, токены Kubernetes service account, а также API-ключи AI-провайдеров и токены инструментов вроде Claude Code и Gemini CLI.
4. Сменить SSH- и GPG-ключи, а также токены GitHub, npm и CI/CD, если они могли присутствовать в окружении с заражённым пакетом.
5. Проверить логи на признаки компрометации — индикаторы (IOC) опубликовали исследовательские команды Aikido, Wiz и Socket.

Источники

• Help Net Security — LiteLLM hit by second supply chain attack this year, users urged to rotate credentials (22 октября 2026)
• The Hacker News — LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoor
• Socket.dev — LiteLLM PyPI Package and Docker Images Compromised to Steal Cloud and AI Credentials