LiteLLM supply-chain: 153 ГБ секретов CI/CD утекли от 2 488 компаний

Коротко: что случилось

13 августа 2026 года исследователи Hudson Rock опубликовали анализ архива из 153 ГБ данных, похищенных в ходе атаки на цепочку поставок LiteLLM. Архив содержит 433 909 файлов, сопоставленных с 2 488 корпоративными доменами, — cloud-ключи, SSH-токены, секреты Kubernetes, ключи AI-провайдеров и переменные окружения CI-раннеров. Источник взлома — PyPI-пакеты LiteLLM версий 1.82.7 и 1.82.8, которые группировка Team PCP скомпрометировала ещё в марте 2026 года, и вредоносный код оставался незамеченным в течение примерно 20 минут активного распространения через пайплайны.

Инцидент напрямую касается команд разработки, использующих LiteLLM в своих проектах разработки под ключ и MLOps-пайплайнах: если вы устанавливали LiteLLM в марте 2026 года и обновляли зависимости автоматически, ваши секреты CI/CD могут находиться в утёкшем архиве. ФБР ещё в июле 2026 предупредило, что Team PCP и связанные с ней группировки продолжают монетизировать украденные учётные данные.

Как строилась атака

Точкой входа стал не сам репозиторий LiteLLM, а Trivy — популярный open-source-сканер уязвимостей, встроенный в build-пайплайн проекта. Team PCP компрометировала его примерно на 20 дней и использовала для внедрения вредоносного кода в момент сборки пакета. Получившиеся версии 1.82.7 и 1.82.8 попали на PyPI и оставались там около 40 минут — достаточно, чтобы автоматические CI-пайплайны тысяч компаний их скачали и установили.

После установки вредонос разворачивал атаку в три этапа. Сначала он собирал учётные данные: ключи облаков (AWS, GCP, Azure), AI-провайдеров (OpenAI, Anthropic, Cohere), SSH-ключи, токены репозиториев и переменные окружения. На втором этапе он пытался перемещаться латерально по Kubernetes-кластерам, куда имел доступ через похищенные токены. Третий этап — установка постоянного systemd-бэкдора, опрашивающего командный сервер за новыми командами.

Среди компаний, чьи данные Hudson Rock обнаружил в архиве: NVIDIA, Microsoft, Volkswagen, FedEx, S&P Global, John Deere, Epic Games, Orange, TomTom, BT Group, ServiceNow, Deloitte и Siemens. Это показывает, как атака через один популярный PyPI-пакет для работы с LLM распространяется на широкий корпоративный сектор.

Почему это особенно опасно для AI-команд

LiteLLM — это единый OpenAI-совместимый прокси для LLM-провайдеров: через него команды роутят запросы к OpenAI, Anthropic, Google, Cohere и десяткам других провайдеров из одной точки кода. Это означает, что в его окружении концентрируются API-ключи сразу нескольких провайдеров — высокоценная цель.

По данным анализа архива, среди украденного особенно много ключей AI-провайдеров и CI-раннер-дампов. CI-раннеры запускают тесты, сборки и деплои с секретами в переменных окружения; один дамп может содержать доступ к production-окружению, облачному провайдеру и Docker-реестру одновременно. Именно поэтому ФБР рассматривает такие credential-сеты как «длинные ключи» — злоумышленники способны применять их месяцами, постепенно монетизируя через облачные вычисления, перепродажу доступа или шантаж.

Кроме того, случай с LiteLLM — наглядная демонстрация атаки типа «атака через инструмент безопасности»: Trivy сам является сканером уязвимостей, то есть именно тот компонент, который призван защищать пайплайн, стал вектором компрометации. Этот паттерн повторяется в SolarWinds, 3CX и CodeCov — и будет повторяться.

Что делать прямо сейчас: чеклист для команд

Первое и неотложное — проверьте, устанавливала ли ваша инфраструктура LiteLLM в период с марта по апрель 2026 года. Если CI-пайплайны обновляют зависимости без закрепления версий (unpinned dependencies), вероятность установки скомпрометированных версий высока.

Если установка подтверждена или есть подозрение — ротируйте все секреты немедленно, не дожидаясь анализа. Это означает: все API-ключи AI-провайдеров, SSH-ключи раннеров, облачные IAM-ключи (AWS Access Key, GCP Service Account, Azure Client Secret), токены Docker/container registry, NPM/PyPI publish credentials и секреты Kubernetes. Ротация занимает часы; ущерб от того, что ключи уже используются злоумышленниками, может оказаться несоразмерно больше.

После ротации проведите аудит Kubernetes-кластеров на предмет новых ServiceAccount-токенов, неожиданных Pod'ов и аномальных network-политик. Проверьте systemd-юниты на хостах, где выполнялись CI-раннеры, на наличие незнакомых сервисов.

В качестве системной меры — перейдите на закрепление версий зависимостей с хеш-верификацией. Для Python-проектов это `pip install litellm==X.Y.Z --require-hashes` с manifest-файлом; для npm — `package-lock.json` с `npm ci`. Дополнительно — добавьте проверку целостности пакетов (Sigstore/Cosign для контейнеров, PyPI OIDC-атtestations) в стадию CI перед установкой любых зависимостей.

Контекст: supply-chain атаки на AI-экосистему участились

Инцидент с LiteLLM — не изолированный случай. В 2025–2026 годах было зафиксировано несколько крупных supply-chain атак, направленных именно на AI/ML-экосистему: компрометация пакетов для работы с embeddings, атаки на huggingface_hub и torch-нотации в открытых датасетах. Закономерность — злоумышленники идут туда, где сосредоточены ключи с высокой стоимостью доступа, а AI-инструменты всё чаще имеют в своём окружении ключи к production-моделям и sensitive-данным.

Отдельного внимания заслуживает вектор через инструменты безопасности и DevOps. Trivy, Renovate, GitHub Actions marketplace-actions, npm preinstall/postinstall scripts — всё это компоненты, которые исполняются с расширенными привилегиями в доверенном окружении сборки. Именно поэтому принцип безопасной разработки требует рассматривать каждый инструмент в пайплайне как потенциальную поверхность атаки, а не только сам код приложения.

Часто задаваемые вопросы

Какие версии LiteLLM скомпрометированы? Вредоносный код был внедрён в версии 1.82.7 и 1.82.8 на PyPI. Эти версии были удалены, однако если они попали в кеш или закэшированный слой Docker-образа — они могут присутствовать в вашей инфраструктуре до сих пор.

Как проверить, затронута ли моя организация? Hudson Rock запустил инструмент самопроверки для организаций — проверьте корпоративный домен через их портал раскрытия информации. Однако отсутствие домена в базе не означает отсутствие компрометации: архив анализируется не полностью, а часть dump'ов может не содержать явных доменных маркеров.

ФБР выпустило предупреждение — что именно оно рекомендует? В июльском advisory ФБР рекомендует немедленную ротацию всех учётных данных, аудит активности IAM-аккаунтов за период с марта по август 2026 года и включение MFA на всех privileged-аккаунтах. Дополнительно — мониторинг CloudTrail/Activity Logs на нетипичное использование API-ключей в нерабочие часы или из нестандартных регионов.

Это нас касается, если мы используем LiteLLM через Docker? Если образ был собран с использованием скомпрометированных версий и не пересобран с тех пор — да. Слой с вредоносным пакетом может присутствовать в кеше образа. Пересоберите образ с чистой версией LiteLLM и проверьте все CI-секреты, использовавшиеся при сборке.

Источники

The Hacker News — Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations, 13 августа 2026 (Tier-1, первое раскрытие).

Help Net Security — 153GB of stolen credentials surface after LiteLLM supply chain attack, 13 августа 2026 (Tier-1, анализ архива Hudson Rock).

Cycode — LiteLLM Supply Chain Attack: What Happened and How to Respond, технический разбор механики атаки.