Исследователи в области безопасности выявили то, что они называют крупнейшим инцидентом в цепочке поставок ИИ на сегодняшний день в 2026 году, и масштабы этого события поражают. По данным компании по анализу угроз CloudSEK, компрометация, связанная с широко используемым проектом LiteLLM, могла затронуть более чем 2 500 компаний и примерно 434 000 конвейеров CI/CD по всему миру. Один только масштаб делает этот инцидент одной из наиболее значимых атак на цепочку поставок программного обеспечения в экосистеме ИИ, и последствия до сих пор разбираются спустя месяцы.
Summary
Ключевые выводы
- В реконструированном наборе данных об экспозиции CloudSEK перечислены более 2 500 компаний и 434 000 конвейеров CI/CD, потенциально подвергшихся воздействию в результате утечки.
- Группа злоумышленников, известная как Team PCP, организовала атаку в марте 2026 года, скомпрометировав пакеты LiteLLM в PyPI версий 1.82.7 и 1.82.8.
- Исходной точкой входа стал сканер безопасности Trivy, использовавшийся внутри конвейера сборки LiteLLM, который оставался скомпрометированным примерно 20 дней.
- По сообщениям, похищенные данные включают облачные ключи, токены репозиториев, SSH-ключи, секреты Kubernetes, учетные данные для публикации пакетов, переменные окружения и ключи провайдеров ИИ.
- ФБР выпустило уведомление FLASH в июле 2026 года, предупредив, что похищенные учетные данные все еще могут быть использованы в будущих атаках.
Крупнейший инцидент в цепочке поставок ИИ в 2026 году раскрыл данные более 2 500 компаний
Расследование CloudSEK указывает на утечку такого масштаба, что она смогла проникнуть в программные конвейеры тысяч организаций, многие из которых не имели прямых отношений с скомпрометированным проектом, кроме использования его как зависимости. Такова природа современных цепочек поставок ПО: один отравленный пакет может распространить последствия на бесчисленное количество не связанных между собой компаний.
Крупные организации, указанные в наборе данных об экспозиции
Среди организаций, которые CloudSEK отметила как совпадения с высокой степенью уверенности в своем наборе данных об экспозиции, — NVIDIA, Amazon Web Services (AWS), Cisco Systems, Salesforce, Siemens AG, X Corp (Twitter) и Orange S.A., а также десятки других глобальных предприятий из сфер финансов, телекоммуникаций, производства и обороны. CloudSEK подчеркивает, что «высокая уверенность» отражает силу доказательств экспозиции, а не подтвержденный факт того, что организация действительно была скомпрометирована или что данные были украдены и использованы. Тем не менее, само упоминание в подобном наборе данных достаточно, чтобы запустить срочную внутреннюю проверку, и несколько из указанных организаций управляют инфраструктурой, лежащей в основе значительной части интернета и корпоративных облачных вычислений.
Это важно, потому что утечка такого масштаба затрагивает не только линейку продуктов одной компании — она потенциально касается учетных данных и конвейеров, соединяющих облачные аккаунты, системы контроля версий, SaaS-платформы и провайдеров ИИ, используемых по целым отраслям.
Как развивалась атака: от Trivy к LiteLLM
Утечка началась не с самого LiteLLM, а с доверенного инструмента внутри его процесса сборки. Злоумышленники захватили контроль над сканером безопасности Trivy, на который опирался конвейер CI LiteLLM, используя утекший токен автоматизации, который был ротирован, но так и не был полностью отозван. Этот пробел оставил примерно 20-дневное окно, в течение которого атакующие могли принудительно отправлять вредоносный код поверх опубликованных тегов версий Trivy — код, который по-прежнему выглядел легитимным для всех, кто находился ниже по цепочке.
Оттуда отравленный сканер автоматически попал в собственную систему сборки LiteLLM, которая затем создала и опубликовала два скомпрометированных релиза в Python Package Index: версии 1.82.7 и 1.82.8. По данным CloudSEK, эти пакеты находились в PyPI примерно 40 минут — узкое окно, которого, тем не менее, оказалось достаточно, чтобы посеять глобальный инцидент экспозиции, поскольку автоматизированные конвейеры устанавливают зависимости с машинной скоростью и часто работают с широкими системными привилегиями.
Вредоносный код выполнялся через файл `.pth`, который запускается автоматически при старте Python, что означало, что даже явный импорт LiteLLM не был необходим для его активации. Эта деталь позволила полезной нагрузке обойти типичные защитные механизмы на этапе установки, на которые полагаются команды безопасности.
Что украли злоумышленники
После запуска вредоносное ПО повышало привилегии и собирало широкий спектр чувствительных данных с затронутых систем. Сообщается о следующих категориях эксфильтрованных данных:
- Облачные учетные данные для AWS, GCP и Azure, а также токены Kubernetes и пути к учетным записям сервисов.
- Токены репозиториев, SSH-ключи и учетные данные для публикации пакетов на платформах контроля версий и регистрах.
- Переменные окружения и файлы `.env`, содержащие секреты приложений.
- Ключи провайдеров ИИ и данные конфигурации шлюзов, связанные с более широкой ИИ-инфраструктурой организаций.
По данным CloudSEK, украденные данные шифровались и в некоторых случаях отправлялись на домен-тайпсквот, а там, где эксфильтрация не удавалась, вредоносное ПО, по сообщениям, создавало публичный репозиторий в учетной записи GitHub жертвы и загружало туда украденные данные как релиз-артефакт — что означало, что некоторые организации могли сами непреднамеренно публиковать свои секреты в открытый доступ, не осознавая этого. Поскольку эти учетные данные могут давать доступ к облачным аккаунтам, репозиториям, SaaS-платформам и системам провайдеров ИИ, практические последствия этого инцидента в цепочке поставок ИИ выходят далеко за рамки самого пакета LiteLLM.
Продолжающиеся риски и что будет дальше
Угроза не исчезла после того, как вредоносные пакеты были удалены из PyPI. Похищенные учетные данные остаются пригодными к использованию в течение недель или месяцев, если их активно не ротировать, и именно поэтому вмешались федеральные власти.
Предупреждение ФБР и ротация учетных данных
ФБР выпустило уведомление FLASH в июле 2026 года (FLASH-20260702-01), предупредив, что участники, связанные с этой кампанией, с высокой вероятностью будут использовать похищенные учетные данные в качестве оружия задолго после первоначального вторжения — сигнал о том, что дальнейшие атаки на цепочку поставок, вытекающие из этой утечки, остаются вполне реальной возможностью. Это одна из причин, по которой CloudSEK подчеркивает, что ротации только ключа LiteLLM или одного ключа провайдера модели недостаточно. Любые учетные данные, доступные скомпрометированному процессу — хранятся ли они на диске, находятся в памяти, внедряются в задачу или доступны через сервис метаданных инстанса, — должны рассматриваться как потенциально скомпрометированные, пока не будет доказано обратное.
Такое широкое требование по ротации сложнее, чем кажется. На практике это означает, что командам безопасности необходимо инвентаризировать каждую учетную запись и каждый секрет, к которым мог получить доступ скомпрометированный конвейер, а не только очевидные, связанные с отравленным пакетом.
CloudSEK AIvigil и мониторинг ИИ-инфраструктуры
CloudSEK рассматривает этот инцидент как доказательство того, что ИИ-инфраструктура — шлюзы, среды выполнения агентов, векторные базы данных и серверы MCP — становится стратегической целью с высокой ценностью именно потому, что она находится на стыке данных, идентичности и автоматизированных действий в масштабах всей организации. Платформа AIvigil построена вокруг этой идеи, непрерывно отслеживая ИИ-инфраструктуру, чтобы выявлять скомпрометированные учетные данные, неуправляемые теневые ИИ-активы и рискованные агентные рабочие процессы до того, как они превратятся в полноценные векторы атаки.
Более широкий вывод, который исследователи делают из этого эпизода, заключается в том, что компрометация одного инструмента, связанного с ИИ, — в данном случае сканера безопасности, находящегося на три шага от конечной цели, — может раскрыть целую сеть взаимосвязанных идентичностей и систем. По мере того как ИИ-компоненты все глубже встраиваются в повседневные процессы разработки и бизнес-операции, радиус поражения от одной компрометации на верхнем уровне цепочки только увеличивается.
FAQ
Сколько компаний потенциально подверглись воздействию в результате инцидента в цепочке поставок ИИ с LiteLLM?
Согласно реконструированному набору данных об экспозиции CloudSEK, потенциально пострадали более 2 500 компаний.
Какие типы учетных данных были украдены в ходе утечки?
По сообщениям, украденные учетные данные включали облачные ключи, токены репозиториев, SSH-ключи, секреты Kubernetes, учетные данные для публикации пакетов, переменные окружения и ключи провайдеров ИИ.
Как злоумышленники скомпрометировали пакеты LiteLLM?
Злоумышленники скомпрометировали доверенный сканер безопасности Trivy, использовавшийся в конвейере CI LiteLLM, и внедрили вредоносный код в пакеты LiteLLM в PyPI версий 1.82.7 и 1.82.8.
Какие рекомендуемые шаги для организаций, пострадавших от этой утечки?
Пострадавшим организациям рекомендуется широко ротировать все скомпрометированные учетные данные, изолировать затронутые системы, пересобрать среды из чистых источников, отслеживать поведение рантайма CI/CD и постоянно мониторить свою ИИ-инфраструктуру в дальнейшем.
{«@context»:»https://schema.org»,»@type»:»FAQPage»,»mainEntity»:[{«@type»:»Question»,»name»:»Сколько компаний потенциально подверглись воздействию в результате инцидента в цепочке поставок ИИ с LiteLLM?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Согласно реконструированному набору данных об экспозиции CloudSEK, потенциально пострадали более 2 500 компаний.»}},{«@type»:»Question»,»name»:»Какие типы учетных данных были украдены в ходе утечки?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»По сообщениям, украденные учетные данные включали облачные ключи, токены репозиториев, SSH-ключи, секреты Kubernetes, учетные данные для публикации пакетов, переменные окружения и ключи провайдеров ИИ.»}},{«@type»:»Question»,»name»:»Как злоумышленники скомпрометировали пакеты LiteLLM?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Злоумышленники скомпрометировали доверенный сканер безопасности Trivy, использовавшийся в конвейере CI LiteLLM, и внедрили вредоносный код в пакеты LiteLLM в PyPI версий 1.82.7 и 1.82.8.»}},{«@type»:»Question»,»name»:»Какие рекомендуемые шаги для организаций, пострадавших от этой утечки?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Пострадавшим организациям рекомендуется широко ротировать все скомпрометированные учетные данные, изолировать затронутые системы, пересобрать среды из чистых источников, отслеживать поведение рантайма CI/CD и постоянно мониторить свою ИИ-инфраструктуру в дальнейшем.»}}]}
Статья подготовлена при содействии искусственного интеллекта и проверена редакционной командой.
