Две злонамерени версии на LiteLLM престояха в PyPI за около 40 минути през март, съдържайки код за кражба на идентификационни данни, способен да извлича облачни ключове, SSH ключове, Kubernetes токени, пароли за бази данни и други тайни от системи, които са ги инсталирали.

Фирмата за разузнаване на заплахи CloudSEK съобщава, че набор от данни, който е придобила и който е съставен от около 434 000 файла, заловени от атакуващите, показва потенциално излагане на риск за повече от 2500 организации.

Тези числа не представляват броя на потвърдените жертви. CloudSEK сподели пред The Hacker News, че материалът произхожда от конфиденциални източници на разузнавателна информация и се състои от заграбена плячка и лог файлове, за които е оценено, че принадлежат на кампанията, а не от данни, събрани от самите организации. С други думи, файловете са били откраднати.

Съпоставянето с висока степен на достоверност потвърждава от чии системи произхожда всеки файл. Тази оценка се основава на идентификационни сигнали в компрометираната CI среда за изпълнение, основно идентичност на хоста и легитимни домейни на авторите на промените, като собственият домейн на организацията трябва да се появи, преди съпоставката да получи най-висока оценка.

Имената на пространствата на хранилищата поддържат само оценка със средна степен на достоверност. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens и X Corp са сред засегнатите имена, но нито едно от тях не доказва, че откраднатите идентификационни данни са били използвани, поради което CloudSEK и LiteLLM съветват засегнатите страни да сменят паролите и ключовете си, вместо да чакат доказателства.

LiteLLM е AI портал с отворен код, използван за свързване на приложения с множество доставчици на модели. Проектът идентифицира версии 1.82.7 и 1.82.8 като компрометирани и съобщи, че са били активни на 24 март от 10:39 UTC за около 40 минути, преди PyPI да ги постави под карантина, въпреки че съветва потребителите да третират всяка инсталация в този ден до 16:00 UTC като подозрителна.

The Hacker News потвърди чрез PyPI на 12 август, че нито една от двете версии не фигурира в историята на пакета, докато версии 1.82.6 и 1.83.0 остават достъпни.

ФБР предупреди в свой съвет от 2 юли (FLASH-20260702-01), че свързаните злонамерени субекти вероятно ще използват идентификационни данни, източени по време на кампанията TeamPCP, дълго след първоначалното компрометиране. Агенцията посъветва организациите да подменят CI/CD тайните, токените за публикуване и облачните идентификационни данни, достъпни по време на съответните прозорци на излагане на риск.

Дългосрочен секретен ключ, копиран през този прозорец, статичен облачен ключ, SSH ключ или токен за публикуване остава използваем, освен ако не е бил подменен или анулиран. Ето защо насоките на бюрото са насочени към идентификационните данни, а не към самия пакет, и защо както ФБР, така и Aqua съветват екипите да преминат от дългосрочни токени към временни такива.

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

Компрометираните пакети бяха проектирани да събират променливи на средата, SSH ключове, облачни идентификационни данни, Kubernetes токени и пароли за бази данни, преди да шифроват и изпратят откраднатите данни към models.litellm[.]cloud – домейн под контрола на атакуващите, който не е свързан с проекта.

Анализът на кампанията от Unit 42 отчита, че злонамереният код чете променливи на средата, съдържащи API ключове за модели, включително OPENAI_API_KEY и ANTHROPIC_API_KEY.

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

Инцидентът с LiteLLM е част от по-широка кампания срещу веригата за доставки от страна на TeamPCP, свързана със скенера Trivy на Aqua Security. Google проследява TeamPCP под името UNC6780. Aqua заяви, че атакуващите са запазили достъп след непълна подмяна на идентификационни данни и на 19 март са наложили злонамерени промени в 76 от 77 тага за версии на trivy-action и във всички седем тага за setup-trivy, като същевременно са публикували компрометирана версия на Trivy 0.69.4.

Компрометирането на екосистемата се проследява като CVE-2026-33634, добавено в каталога на CISA за известни експлоатирани уязвимости на 26 март. The Hacker News потвърди на 12 август, че записът на CVE вече посочва BerriAI LiteLLM от 1.82.7 до 1.82.8 като засегнати заедно с компонентите на Trivy.

Точният начин, по който злонамерените версии на LiteLLM са достигнали до PyPI, беше оспорван в публикуваните доклади. Докладът на CloudSEK твърди, че компрометираната компилация е произвела и публикувала версиите, докладът за инциденти на самия LiteLLM посочва директно качване в PyPI, заобикалящо официалния CI/CD работен процес, а Unit 42 описва, че атакуващите са се насочили към токени за публикуване в PyPI след пробива в Trivy.

Запитани за несъответствието, от CloudSEK възразиха. „Това са различни етапи от една и съща верига на атака, а не конкуриращи се обяснения“, заявиха от компанията пред The Hacker News. Техните доказателства обхващат начина, по който е получена идентификационната информация, докато констатациите на LiteLLM и Unit 42 обхващат как тя е била използвана след това.

Предупреждението на PyPA за злонамерените версии описва същата последователност: API токен, изложен чрез компрометираната зависимост на Trivy, е бил използван след това за качване на двете версии.