Злам LiteLLM міг зачепити понад 2 500 організацій

CloudSEK повідомила, що реконструйований набір даних, пов’язаний із березневою атакою на ланцюг постачання LiteLLM, охоплює понад 2 500 організацій і близько 434 000 CI/CD-конвеєрів. Ці числа показують потенційне викриття, а не доводять крадіжку облікових даних у кожної організації. Проте межа реагування зрозуміла: якщо система встановила LiteLLM 1.82.7 або 1.82.8, самого видалення пакета недостатньо.

Інцидент почався зі скомпрометованого шляху сканера Trivy й дістався процесу публікації LiteLLM у PyPI. Шкідливі випуски могли збирати секрети, доступні Python або середовищу збірки, створювати закріплення та розширювати доступ до хмарних і Kubernetes-середовищ. Командам потрібно перевірити історичні встановлення, локалізувати уражені системи та замінити всі облікові дані, які міг прочитати процес, а не лише ключ постачальника ШІ.

Кому потрібно перевірити LiteLLM

Офіційне повідомлення LiteLLM називає 1.82.7 і 1.82.8 скомпрометованими випусками PyPI. Їх опублікували 24 березня 2026 року, починаючи з 10:39 UTC, а невдовзі PyPI помістив їх у карантин. Ризик існує, якщо незакріплена команда pip install litellm, збірка образу, CI-завдання або транзитивна залежність отримали одну з цих версій у відповідний проміжок.

Офіційний сервіс LiteLLM Cloud і офіційний Docker-образ LiteLLM Proxy не були уражені через цей пакетний шлях. Запис у lockfile також не доводить виконання шкідливого коду. Рішення слід будувати на кешах пакетів, журналах CI, шарах образів, історії runner-систем і точній встановленій версії.

• Лише залежність або запис у lockfile: З’ясуйте, чи версію 1.82.7 або 1.82.8 завантажували, встановлювали, кешували або запускали.
• Збірка або хост встановили уражену версію: Ізолюйте runner чи хост, збережіть журнали та вважайте доступні секрети потенційно викритими.
• Пакета вже немає в поточному середовищі: Не вважайте інцидент закритим: перевірте старі образи, кеші, журнали, закріплення та використання токенів.
• Облікові дані були доступні процесу: Відкличте й замініть їх після локалізації, а потім перевірте використання з невідомих ідентичностей, мереж або навантажень.

Як злам сканера дістався інфраструктури ШІ

1. Trivy став початковою ланкою. Зловмисники використали доступ до шляху випуску сканера безпеки та отримали облікові дані з підлеглих середовищ збірки.
2. Було викрито дані публікації LiteLLM. Довірений доступ дозволив розмістити шкідливі випуски в PyPI поза звичайним релізом проєкту.
3. Python запускав навантаження. Версія 1.82.8 містила litellm_init.pth, який Python міг обробити під час запуску інтерпретатора, навіть якщо код застосунку не імпортував LiteLLM.
4. Процес відкривав доступ до навколишніх секретів. Цілями ставали змінні середовища, SSH-ключі, хмарні облікові дані, токени Kubernetes, паролі баз даних та інші доступні відомості.
5. Викрадений доступ переживав пакет. Видалення шкідливого wheel-файлу не відкликає скопійовані секрети й не прибирає закріплення з хостів і кластерів.

Саме цим інцидент з обліковими даними відрізняється від звичайного сповіщення про пакет. У матеріалі про NUL1DROPPER у npm також показано, чому наявність залежності й виконання шкідливого шляху потрібно перевіряти окремо.

Що перевірити й які секрети замінити

1. Відновіть історію встановлень. Шукайте дві точні версії та часовий проміжок 24 березня у журналах CI, кешах пакетів, шарах контейнерів, SBOM, виводі менеджера залежностей і середовищах розробників.
2. Локалізуйте систему до заміни секретів. Зупиніть уражені runner-системи, ізолюйте хости й кластери, збережіть потрібні журнали та перебудуйте середовище з відомих чистих джерел.
3. Перевірте виконання й закріплення. Шукайте litellm_init.pth, ~/.config/sysmon/sysmon.py, неочікувані служби systemd, підозрілий вихідний трафік, невідомі токени та привілейовані навантаження Kubernetes, яких немає в історії розгортання.
4. Замініть увесь доступний набір. Включіть API-ключі постачальників моделей, дані AWS/GCP/Azure, токени GitHub або GitLab, дані реєстрів пакетів, токени service account Kubernetes, паролі баз даних, SSH-ключі, ключі підпису й секрети SaaS.
5. Шукайте повторне використання. Перевірте журнали хмар, систем контролю коду, реєстрів, кластерів та ідентичностей на невідомі IP-адреси, service account, репозиторії, випуски, сесії й зміни навантажень після викриття.
6. Закрийте той самий шлях. Закріплюйте пакети й CI-actions за перевіреними версіями або хешами, скорочуйте строк дії та права токенів, розділяйте облікові дані збірки й публікації та віддавайте перевагу workload identity перед довготривалими статичними секретами.

Поточна чиста версія не стирає історичні докази. Якщо викритим міг бути API-ключ постачальника ШІ, скористайтеся окремим планом реагування на викрадення API-ключів ШІ. Для ширшого контексту розробницького ланцюга дивіться також матеріал про отруєне розширення VS Code та внутрішні репозиторії GitHub.

Хибні припущення, які залишають доступ зловмиснику

• «Ми не імпортували LiteLLM». Механізм .pth міг спрацювати під час запуску Python.
• «Пакет уже видалено». Скопійовані облікові дані, активні сесії, змінені навантаження й закріплення переживають видалення пакета.
• «Ми замінили ключ OpenAI». Процес міг мати доступ також до хмари, репозиторію, кластера, бази даних, SSH і реєстру.
• «Організація є в наборі даних, отже злам підтверджено». Набір даних — це підстава для перевірки; факт встановлення й доступу мають підтвердити локальні журнали та артефакти.
• «Було уражено кожне розгортання LiteLLM». Офіційний LiteLLM Cloud і офіційний закріплений Docker-образ Proxy не належали до скомпрометованого шляху PyPI.

Джерела

1. CloudSEK. «2,500+ Companies and 434,000 CI/CD Pipelines Exposed in the Largest AI Supply Chain Breach of 2026», опубліковано 11 серпня 2026 року; дата звернення: 12 серпня 2026 року. аналіз масштабу викриття.
2. LiteLLM. «Security Update: Suspected Supply Chain Incident», опубліковано 24 березня 2026 року; оновлено 30 березня 2026 року; дата звернення: 12 серпня 2026 року. офіційні поради щодо інциденту.
3. Aqua Security. «Update: Ongoing Investigation and Continued Remediation», оновлено в березні 2026 року; дата звернення: 12 серпня 2026 року. оновлення щодо інциденту Trivy.