В петък LiteLLM разкри, че главен ключ на Agent Platform, случайно публикуван в публично GitHub хранилище в края на май 2026 г., в крайна сметка е позволил на автора на заплахата да качи злонамерена версия на популярния Python пакет.

„На 27 май 2026 г. в публичното хранилище LiteLLM-Labs/lite-harness беше качен конфигурационен файл, който по невнимание съдържаше главния ключ за инсталация на LiteLLM Agent Platform – инструмент с отворен код, който използваме за оркестрация на агенти“, заявяват Оливър Йенсен и Матео Уанг от LiteLLM.

„Грешката беше бързо забелязана, комитът беше презаписан с force push и установихме, че изложените ключове трябва да бъдат отменени. Въпреки това отмяна на главния ключ не беше извършена.“

LiteLLM съобщават, че неизвестният атакуващ (действащ от адрес 69.48.229[.]143) е използвал този неотменен ключ на 10 октомври 2026 г., за да получи достъп до Agent Platform и да извлече OAuth токен на GitHub CLI, с който услугата е била конфигурирана, за да позволява на самостоятелно хоствани облачни агенти да подават pull заявки към GitHub хранилища.

Според разработчиците на LLM шлюза с отворен код токенът е бил „без ограничен обхват“ и е бил свързан с акаунта на собственика на GitHub организацията.

Достъпът до токена е дал на атакуващия права на собственик върху всички хранилища в организацията и възможност за допълнително извличане на идентификационни данни. Последователността от действия на автора на заплахата след тази стъпка е следната:

  • 10 октомври 2026 г., между 22:11 и 22:12 UTC: Авторът качва комити в временни клонове във вътрешни хранилища, за да изпълни работни процеси (BerriAI/litellm и BerriAI/litellm-auto), предназначени да вземат OAuth токени на GitHub CLI на двама инженери с права на поддържащи (maintainer) чрез контролирана от атакуващия крайна точка на webhook[.]site. Двата изпълнения са изтрити минути по-късно.
  • 21 октомври 2026 г., между 10:08 и 11:08 UTC: Заобикаляне на защитата на клона и промяна на конвейера за издаване на версии, като източникът е сменен с хранилището-двойник „Berri-AI/litellm“ вместо „BerriAI/litellm“.
  • 21 октомври 2026 г., между 11:39 и 11:40 UTC: Версия 1.107.0 на LiteLLM е публикувана в PyPI.
  • 21 октомври 2026 г., 11:46 UTC: Публикувани са образи в Docker Hub и GHCR.
  • 21 октомври 2026 г., между 11:53 и 11:54 UTC: Изтрити са записите за изпълнения в продукционната и тестовата среда.
  • 21 октомври 2026 г., 12:06 UTC: Атаката по веригата на доставки е докладвана от изследователя на Upwind Лидор Мачлуф.
  • 21 октомври 2026 г., 13:23 UTC: PyPI поставя версия 1.107.0 на LiteLLM под карантина.
  • 21 октомври 2025 г., 14:20 UTC: Таговете в Docker Hub v1.107.0, latest, main-latest и main-stable са премахнати или пренасочени към проверени чисти образи.

„При нормална работа изграждането и публикуването на версия изисква да бъде инициирано от оторизиран инженер и одобрено от специален акаунт, вързан към физическо устройство в нашия офис“, заявяват от LiteLLM.

Изтекъл главен ключ през май 2026 г.

„Това ограничение беше облекчено по-рано тази седмица, за да се улесни временното ускоряване на изданията и пренасянето на корекции на грешки, като позволяваше на всеки двама инженери да задействат и одобрят издаване. Така авторът на заплахата използва един от токените, за да задейства издаването (след като пренасочи инструмента за внедряване към злонамереното си хранилище), и друг, за да го одобри.“

Освен това поддържащите проекта отбелязват, че авторът на заплахата е могъл сам да облекчи това ограничение (или да го премахне изцяло), тъй като вече е притежавал токен на собственик на организацията. Предполага се, че това не е направено, за да се избегне разкриване.

LiteLLM съобщават също, че работните процеси са проектирани да откриват и извличат допълнителни ключове и токени, като специално се целят в токени за API за инференция от външни доставчици. В отговор на инцидента компанията заяви, че работи по отмяната на всеки токен, свързан с всяка вътрешна система и платформа на доставчик.

Излизат нови подробности за работните процеси

Socket, които публикуваха собствено разследване на злонамерените работни процеси, съобщават, че са възстановили два злонамерени комита, всеки от които добавя работен процес в „.github/workflows/cache.yml“. Първият комит е направен на 10 октомври 2026 г. в 22:11:45 UTC. Следван е от втори комит на 12 октомври.

„Нито един от комитите не е изпратен в клон, който все още съществува“, заяви изследователят по сигурност на Socket Карло Занки в доклад, споделен с The Hacker News. „И двата са изпратени в краткотрайни клонове с имена ci-tmp-<hex>, които са създадени, използвани и изтрити в рамките на минути, поради което активността оставя почти нищо в обикновената история на хранилището.“

Според анализа на фирмата за сигурност на приложения върху записите в журнала за активност на хранилището и двата комита използват легитимен комит като основа на клона, за да изглежда изпращането привидно безобидно:

  • Създава се временен клон с име „ci-tmp-<hex>“ (а именно ci-tmp-a351cc и ci-tmp-4d8517) от скорошен легитимен комит в хранилището.
  • Изпраща се комит, добавящ „.github/workflows/cache.yml“ със същото заглавие: „ci: bump cache config“.
  • Работният процес е конфигуриран да се изпълнява при всяко изпращане на комит или таг (т.е. „on: [push]“), което го задейства.
  • Клонът се изтрива.

И двата работни процеса, както подчертават от LiteLLM, са създадени да събират токени за GitHub и API ключове за работното пространство Linear на организацията, за внедряването на LiteLLM и за Together AI, заедно с идентификатора и ключа за подписване на GitHub App.

Изпълнението от 12 октомври разширява събирането до повече тайни, включително API ключове за Anthropic, OpenAI, AWS Bedrock, Tavily и средата на GitGuardian за сканиране за тайни. То също така извлича състоянието на хранилището на Playwright, информация за PostgreSQL база данни (низ за връзка, име на акаунт, парола), адрес и порт на Redis, както и парола за автентикация.

Събраните от двата работни процеса данни се извличат към две различни крайни точки на webhook[.]site:

  • webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37
  • webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1

„GitHub токенът и частният ключ на GitHub App са идентификационни данни за платформата, хостваща хранилището, а не за външна услуга“, заяви Занки. „GITGUARDIAN_API_KEY е идентификационен данни за самата платформа за сканиране за тайни, което дава на атакуващия видимост и потенциално контрол върху сигналите, които биха разкрили тази активност.

E2E_LINEAR_STORAGE_STATE_B64 е сериализирано състояние на браузърна сесия, използвано от Playwright за end-to-end тестове; валидно състояние на хранилището позволява автентикиран достъп до свързания акаунт в Linear без парола и без изпълнение на многофакторна автентикация.“

Находките опровергават първоначалната хипотеза на LiteLLM, че OAuth токените на GitHub CLI са откраднати от логовете на вътрешна инсталация на LiteLLM. „Разследването беше процес, в който непрекъснато научавахме нова информация, което означава, че някои от предположенията и убежденията ни по-късно се оказаха неточни или непълни“, призна Йенсен.

Какво прави злонамерената версия на пакета

Множество доклади разкриха, че файловете, включени във версия 1.107.0 на LiteLLM, са проектирани да се изпълняват автоматично при стартиране на Python, дори ако приложението не е импортирало LiteLLM.

Зловредният софтуер има два пътя на изпълнение: модул за събиране на идентификационни данни, насочен към автентикационни материали в инструменти за разработчици, AI приложения, облачни среди и уеб браузъри, и бекдор за Unix системи, който се стартира като фонов процес и на всеки час изтегля и изпълнява произволен код, предоставен от атакуващия.

Поток на изпълнение на компрометираната версия LiteLLM 1.107.0

Стийлърът събира още системна информация, SSH файлове, идентификационни данни и токени за Git и GitLab, променливи на средата и токени, свързани с npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems и Cargo. След това данните се компресират и се изпращат към „litellm[.]dev/healthcheck“ чрез HTTP POST заявка. Домейнът е регистриран на 13 октомври 2026 г.

„Взети заедно, тези механизми разширяват потенциалното излагане отвъд активните инсталации на LiteLLM: самото стартиране на Python в засегната среда може да активира злонамерения код, дори когато LiteLLM никога не е бил импортиран“, заяви екипът за изследвания на сигурността на Microsoft.

„Тъй като стартовите файлове се намират извън директорията на приложението LiteLLM, премахването само на файловете на приложението може да остави злонамерените стартови компоненти.“