Секрет, прибраний із публічного коміту в травні, залишався чинним у жовтні — і, за даними LiteLLM, став першим кроком до випуску отруєного пакета. Розслідування від 23 жовтня простежує злам LiteLLM 1.107.0 через невідкликаний ключ платформи та три викрадені ідентичності GitHub. Окремий аналіз Microsoft пояснює наслідок для користувачів: запуск Python в ураженому середовищі міг активувати викрадач облікових даних, навіть якщо застосунок не імпортував LiteLLM. [1][2]
Якщо ви могли встановити уражений випуск, не перевіряйте його через Python чи pip із цього середовища. Ізолюйте його та дослідіть файли й записи розгортання довіреними засобами ззовні. Інтерпретатор, який ви збираєтеся опитати, сам може запустити шкідливий код.
Прибраний коміт залишив робочий ключ
За даними LiteLLM, конфігураційний коміт від 27 травня відкрив головний ключ експериментальної Agent Platform. Коміт перезаписали, але ключ не відкликали. 10 жовтня зловмисник використав його для отримання конфігурації агентів із GitHub CLI OAuth-токеном власника організації.
Так доступ до одного сервісу агентів перетворився на контроль над репозиторіями. Зловмисник запускав робочі процеси репозиторіїв, щоб витягти токени ще двох супроводжувачів. Одна ідентичність могла змінити процес випуску, друга — схвалити публікацію, третя — видалити записи запусків. Різні назви облікових записів уже не означали незалежного схвалення людьми.
У хронології є показовий п’ятисекундний розворот: 21 жовтня о 10:08:29 UTC захист гілки заблокував push із токеном супроводжувача, а о 10:08:34 push із токеном власника пройшов після вимкнення обмежень. Джерело збірки змінили зі справжнього BerriAI/litellm на схожий Berri-AI/litellm. LiteLLM описує початковий доступ за власним розслідуванням; Microsoft не встановлювала незалежно, як було отримано облікові дані розробників.
Пакет виніс запуск за межі LiteLLM
Microsoft знайшла cook.pth, cook.py та sitecustomize.py у каталозі бібліотек Python-середовища, поза звичайною папкою застосунку LiteLLM. Їх міг завантажити штатний механізм запуску Python. Видалення самої папки litellm залишало цей шлях виконання.
Збирач шукав доступні для читання облікові дані інструментів розробки й ШІ, конфігурацію хмар, SSH-матеріали, дані браузерів і змінні середовища. Microsoft спостерігала відповідні дії з пошуку, шифрування й мережевого обміну у Windows та macOS; в одному Windows-випадку збирання запустило встановлення іншої залежності.
Другий, орієнтований на Unix шлях міг отримувати додатковий Python-код через змінний віддалений покажчик, але завантаження й виконання цього другого етапу не підтверджені. Так само наявність цілі в коді збирача не доводить, що кожен секрет вдалося прочитати чи передати. Встановлений пакет підтверджує ризик викриття; завершену крадіжку потрібно зіставляти з процесами, файлами, мережевими й обліковими журналами.
Чистий тег коду не виправдовує завантажений образ
LiteLLM називає ураженими всі сім PyPI-wheel версії 1.107.0: їх опублікували 21 жовтня між 11:39:51 і 11:40:13 UTC та помістили в карантин до 13:23. Образи Docker Hub із тегами v1.107.0, latest, main-latest і main-stable були уражені з 11:46:56 до 14:20; уражені теги GHCR стали недоступними до 13:51. Приватний корпоративний реєстр не належав до цього інциденту. [3]
Офіційний тег вихідного коду GitHub не містив шкідливих стартових файлів. Тому перевіряти потрібно фактично встановлений wheel або дайджест образу та історію його отримання, а не лише сьогоднішній вміст тегу. Змінний тег уже може вказувати на чистий образ, хоча раніше завантажена копія залишається на робочій станції, агенті збірки чи сервері.
Це окремий жовтневий інцидент, відмінний від березневої атаки на LiteLLM 1.82.7 і 1.82.8. Оцінки масштабу старого випадку не можна переносити на новий.
Перебудуйте середовище й відкличте доступні йому ключі
Із чистої системи перевірте збережені метадані пакетів, lock-файли, кеші, результати збірок і дайджести образів. Ізолюйте уражені вузли та процеси, потім перебудуйте Python-середовище або контейнер із перевірених артефактів. З чистого комп’ютера відкличте доступні процесу ключі постачальників, хмар, репозиторіїв, реєстрів, баз даних, SSH та відповідні сесії; перевірте їх подальше використання. Видалення пакета не повертає скопійовані ключі.
На робочій станції Windows повне сканування за допомогою Gridinsoft Anti-Malware допоможе перевірити додаткові шкідливі файли й механізми закріплення. Перегляньте результати, видаліть виявлені загрози та за потреби перезавантажте систему. Це доповнює перебудову середовища, але не замінює відкликання облікових даних і не доводить відсутності витоку.
Збій перетнув дві межі: нібито видалений секрет усе ще давав доступ, а довірений пакет розмістив виконувані стартові файли поза власною папкою. Відновлення має закрити і середовище виконання, і доступ через облікові дані, які воно могло відкрити.
Окремий випадок в інфраструктурі хостингу — пояснення Railway щодо відкликання нових API-ключів — показує різницю між запобіжним відкликанням і доказом нового викрадення. Завершіть відновлення облікових даних після початкового інциденту, а потім перевірте причину відкликання заміни, перш ніж робити висновок про новий злам.
Джерела
- Олівер Єнсен і Матео Ван. «The attack chain behind the v1.107.0 LiteLLM release». LiteLLM, 23 жовтня 2026 року; дата звернення: 25 жовтня 2026 року. Розслідування розробників.
- Microsoft Security Research. «Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks». Microsoft Security Blog, 23 жовтня 2026 року; дата звернення: 25 жовтня 2026 року. Аналіз коду та рекомендації з реагування.
- LiteLLM. «Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised». 21 жовтня 2026 року, оновлюване повідомлення; дата звернення: 25 жовтня 2026 року. Уражені артефакти та часові межі.
