Технічний контекст
Я занурився в аналіз інциденту, щойно побачив сповіщення, і картина там, м'яко кажучи, неприємна. На PyPI скомпрометували LiteLLM 1.82.7 та 1.82.8, причому шкідливий код опублікували безпосередньо в реєстр 24 березня 2026 року. За даними дослідників, це схоже на продовження ланцюжка після зламу Trivy та крадіжки облікових записів з CI/CD.
Найгірше — це не просто «поганий реліз». У 1.82.8 додали .pth-файл, який виконується під час старту Python-процесу. Тобто в багатьох сценаріях вам навіть не потрібно явно імпортувати LiteLLM, щоб отримати проблему.
Я окремо звернув увагу на список того, що малвар витягує з машини. Там SSH-ключі, .env, AWS/GCP/Azure credentials, конфіги Kubernetes та токени service account, паролі від PostgreSQL, MySQL, Redis, MongoDB, shell history, Vault-токени, npm-токени, webhooks і взагалі все, що схоже на секрети. Якщо хост мав доступ до хмари або кластера, вважайте радіус ураження дуже широким.
Далі ще веселіше. Пакет не тільки викрадає дані, але й намагається закріпитися в системі через sysmon.py, а в Kubernetes — читати секрети по неймспейсах і розгортати привілейовані pod'и в kube-system. Це вже не локальний інфостілер, а повноцінна supply-chain атака зі спробою подальшого поширення.
Що робити просто зараз, якщо у вас десь стояв LiteLLM 1.82.7 або 1.82.8:
- ізолювати хости та runner'и, де пакет міг запускатися;
- знести вразливі версії та почистити кеш pip;
- шукати litellm_init.pth, sysmon.py та підозрілі pod'и в Kubernetes;
- ротувати всі credentials без винятків;
- перевіряти вихідний трафік та логи після 24 березня.
І так, офіційна порада «просто відкотитися» тут недостатня. Якщо пакет хоч раз виконавсь, я б виходив з припущення про повну компрометацію секретів.
Вплив на бізнес та автоматизацію
Для мене це хороший, хоч і болючий, приклад того, що ШІ-автоматизація ламається не тільки через якість моделей та ціну токенів. Вона ламається на ланцюжку постачання. Один популярний пакет для LLM-роутингу — і у вас під загрозою хмара, CI/CD, база, Kubernetes та сервісні акаунти.
Програють команди, які тягнуть залежності в прод «як є», без фіксації версій, без ізоляції runner'ів і без чіткої схеми ротації секретів. Особливо боляче буде тим, хто зробив впровадження ШІ швидко, але без нормальної AI-архітектури: спільний .env, довгоживучі ключі, широкий доступ у сервісів, один Kubernetes-кластер на все підряд. У такій схемі одна бібліотека перетворюється на прохідний двір.
Виграють ті, хто вже будує архітектуру ШІ-рішень через короткоживучі credentials, сегментовані середовища, workload identity та окремі runner'и під збірку. Так, це звучить менш весело, ніж «підключили новий LLM-router за пів години». Але саме так виглядає зріла інтеграція штучного інтелекту, коли автоматизація за допомогою ШІ не ставить під удар всю інфраструктуру.
Ми в Nahornyi AI Lab регулярно стикаємося з цим на практиці: клієнт хоче швидке ШІ-рішення для бізнесу, а я насамперед дивлюся не на промпти, а на секрети, мережеві політики та спосіб доставки залежностей. Тому що впровадження штучного інтелекту сьогодні — це вже не тільки про моделі. Це ще й про те, наскільки легко вашу LLM-обв'язку можна перетворити на точку входу.
Мій практичний висновок простий: LiteLLM як інструмент сам по собі не «помер», але довіра до Python supply chain в AI-стеку знову отримала удар. Після такого я б переглянув фіксацію версій, SBOM, підпис пакетів, правила для egress-трафіку та права сервісних акаунтів. І особливо — все, що пов'язано з Kubernetes та self-hosted runner'ами.
Цей розбір зробив я, Вадим Нагорний з Nahornyi AI Lab. Я займаюся ШІ-автоматизацією на практиці: проєктую LLM-інфраструктуру, розбираю інциденти, створюю безпечні пайплайни та допомагаю не перетворити впровадження ШІ на джерело нових дірок. Якщо хочете, я можу переглянути ваш стек, оцінити радіус ураження і разом з командою Nahornyi AI Lab розібрати ваш конкретний кейс.