CloudSEK пов’язує березневу утечку LiteLLM з 2 500 організаціями

Фірма з кібербезпеки CloudSEK повідомила в звіті, опублікованому 11 серпня 2026 року, що вона виявила понад 2 500 організацій, які потенційно постраждали від березневої утечки в ланцюжку поставок LiteLLM, відкритого джерельного шлюзу, який розробники використовують для маршрутизації запитів через моделі штучного інтелекту, і відтворила близько 434 000 конвеєрів CI/CD, які постраждали від цієї утечки.

Ці цифри походять із дослідницького звіту CloudSEK, створеного на основі набору даних жертв, який компанія говорить, що її команда з кібербезпеки отримала щодо березневої кампанії. Набір даних CloudSEK містить високі співвідношення, пов’язані з корпоративними доменами, репозиторіями, обліковими даними чи інфраструктурою, що належить організаціям, серед яких NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales та London Stock Exchange Group. Компанія явно зазначає, що ці співвідношення означають: висока впевненість описує силу доказів, які пов’язують виявлену інформацію з організацією, а не доказ того, що організація була скомпрометована чи що атакувальник використав те, що було взято.

Інцидент, який став центром дослідження, розпочався 24 березня 2026 року, коли група, відстежувана як TeamPCP, опублікувала шкідливі версії LiteLLM 1.82.7 та 1.82.8 у Python Package Index. Зловмисні релізи були активні близько 40 хвилин, перш ніж їх видалено. Цього вікна було достатньо: конвеєри CI/CD встановлюють залежності автоматично та часто запускаються з широкими привілеями, тому отруєний пакет поширюється через корпоративні системи складання з швидкістю машини без будь-якого огляду розробником.

Як один витік токену досяг 434 000 конвеєрів

LiteLLM ніколи не був атакований безпосередньо. Ланцюг, задокументований у звіті CloudSEK, починається на одному етапі вище, з Trivy, широко використовуваним відкритим джерельним сканером безпеки. Витік автоматизованого токену, пов’язаного зі сканером, був обернений, але не повністю скасований, залишаючи вікно близько 20 днів, протягом якого атакувальники змогли примусово надіслати шкідливий код через опубліковані теги версій сканера. Через те, що власний конвеєр складання LiteLLM встановлював Trivy не закріплений за системним менеджером пакетів, скомпрометований сканер безпосередньо потрапив у складання, а отруєне складання створило та опублікувало шкідливі релізи 1.82.7 та 1.82.8 у PyPI. Один невідкликаний токен, три інструменти глибоко.

Конструкція вантажу зробила коротке вікно суттєвим. Версія 1.82.8 впала шкідливий файл .pth у середовище Python, а файли .pth виконуються щоразу, коли запускається інтерпретатор Python, незалежно від того, чи імпортується LiteLLM. Це повністю обходить захист сценаріїв під час установки. На скомпрометованих виконавцях викрадач облікових даних, який ФБР називає SANDCLOCK, підвищувався до кореня та збирав ключі SSH, облікові дані AWS, Google Cloud та Azure, токени сервісних облікових записів Kubernetes, файли середовища та секрети CI/CD, збираючи значення з пам’яті процесу, яку зазвичай намагаються маскувати інструментами. Ключі хмарних служб прийшли безпосередньо з сервісу метаданих екземпляра, використовуючи доступ, який вже мав виконавець, а не будь-який експлойт. Для будівель штучного інтелекту зокрема вантаж включав ключі API LLM та конфігурацію шлюзу: облікові дані всього штучного інтелекту організації.

Викрадена інформація була зашифрована під жорстким ключем та виведена на домен з помилковим правописом. Там, де виведення зазнало невдачі, шкідливий код створив публічний репозиторій всередині облікового запису жертви в GitHub та завантажив викрадений матеріал туди як актив випуску, що означало, що деякі організації публікували свої власні секрети на виду.

Чому ризик пережив пакет

Видалення шкідливих релізів з PyPI не закрило інцидент. Будь-яка скопійована облікова інформація під час активності отруєного пакету залишається дійсною до тих пір, поки власник не оберне чи не скасує її, а видалення пакету нічого не робить самі по собі. ФБР зробило той же висновок у своєму консультативному документі від 2 липня 2026 року щодо TeamPCP, попередивши, що організації, які постраждали від цієї кампанії, повинні розглядати виведену інформацію та облікові дані як постійний ризик, оскільки пов’язані з цією кампанією актори, ймовірно, озброїють їх довгий час після початкового проникнення.

Консультативний документ підтверджує масштаб кампанії за межами LiteLLM: TeamPCP троянські коні сканера Trivy, сканера KICS компанії Checkmarx, LiteLLM та Python SDK компанії Telnyx, інструментів, вбудованих у корпоративні конвеєри, хмарну інфраструктуру та потоки безпеки, та поєднали ці проникнення з вимаганням викупу, опублікувавши імена жертв на публічному сайті витоків та погрожуючи розголосити викрадену інформацію.

Рекомендовані ФБР заходи щодо пом’якшення майже точно збігаються з тим, що було використано в ланцюжку LiteLLM: закріпити дії GitHub за перевіреними хешами комітів, а не за плаваючими тегами версій, обернути кожний секрет CI/CD та токен публікації, доступний під час вікна уразливості, застосувати найменшу привілейовану сферу дії облікових записів служби та токенів реєстру, та шукати організації GitHub за репозиторіями з назвами tpcp-docs або docs-tpcp, які створюються шкідливим кодом з викраденими обліковими даними.

Що означають мітки впевненості

CloudSEK сортує організації у своєму наборі даних за силою доказів. Висока впевненість ґрунтується на ідентифікованих корпоративних доменах, репозиторіях, облікових даних чи інфраструктурі; середня впевненість містить правдоподібні, але слабші індикатори. Ні одна з цих міток не є доказом успішної атаки, і компанія наголошує, що набір даних є відтвореною уразливістю: появитися в ньому означає, що інформація, пов’язана з організацією, була виявлена та повинна бути розслідувана, а не підтверджує факт проникнення.

Деяка обережність щодо масштабу є слушною. Цифри 2 500 організацій та 434 000 конвеєрів походять з набору даних, який CloudSEK отримала через свої канали розвідки, та відтворила, і компанія продає платформу моніторингу уразливостей AIVigil, на яку вказує цей звіт. Все це не підкреслює кампанію під цим: компрометування LiteLLM, його місце в ширшій операції TeamPCP та класи облікових даних, які знаходяться під загрозою, підтверджуються консультативним документом ФБР та записом інциденту з березня.

CloudSEK опублікувала безкоштовний перевірочний інструмент уразливостей, де організації можуть дізнатися, чи їхня інфраструктура присутня у наборі даних. Її рекомендація для будь-якої збіги полягає в тому, щоб розглядати кожну облікову інформацію, до якої міг мати доступ постраждалий процес, як потенційно уразливу до тих пір, поки не буде підтверджено, переглянути журнали доступу по системам хмар, контролю джерел, реєстру та кластерів, та обернути широко, а не тільки ключ LiteLLM чи постачальника моделі. Для організацій, які запускали постраждалі версії у березні, рішення про обертання вже має п’ятимісячний годинник.