Близо 1 от 10 публично достъпни LiteLLM портала са приемали примерния администраторски ключ „sk-1234“

Почти един на всеки десет от LiteLLM сървърите, достъпни през интернет, които Wiz Research сканира през февруари, е приемал sk-1234 — примерният администраторски ключ в ръководството за инсталация на самия LiteLLM.

LiteLLM е AI портал (gateway) с отворен код — софтуерът, който дадена компания поставя между своите приложения и доставчиците на модели, на които плаща. Този ключ представлява идентификационните данни за администратор на портала.

Всеки, който го притежава, може да прочете API ключа за всеки доставчик на модели, съхранен на сървъра. При тестовете на Wiz той е достигнал и до облачните IAM идентификационни данни на машината, на която работи порталът.

Промяната на ключа не изисква обновяване и затваря всеки вектор на атака в доклада на Wiz, който зависи от притежаването му.

Откъде идва числото

Wiz проведе едно сканиране. То откри 3074 LiteLLM портала в Shodan през февруари, като 294 от тях са приемали ключа.

В 191 от тези 294 изобщо не е бил зададен ключ, така че те биха приели всичко. При останалите стойността от ръководството за инсталация е била оставена без промяна.

Второ сканиране през август откри повече от 85 000 екземпляра, но Wiz заявява, че повечето от тях изглежда са примамки (honeypots) или тестови системи, така че двете стойности не могат да се сравняват. Към момента няма актуална цифра.

Към 9 септември ръководството за инсталация на LiteLLM все още използва sk-1234, разположен над коментар, който указва на операторите да го заменят с дълга случайна стойност преди реална употреба.

Защо един ключ е толкова важен

Главният ключ изпълнява две задачи едновременно и именно това прави стойността по подразбиране толкова сериозен проблем. Той е едновременно администраторски идентификатор и превключвател, който активира автентификацията.

Преди версия 1.82.0-stable портал, стартиран без главен ключ, предоставяше пълни администраторски права на всяка входяща заявка.

Администраторът на един от тези сървъри разполага с широк достъп. Порталът може да съхранява API ключ за всеки доставчик, към когото пренасочва, да вижда всеки подкана (prompt) и отговор, преминаващи през него, и да се свързва с вътрешни инструменти чрез Model Context Protocol (MCP).

Освен това той обикновено работи с облачните разрешения на работния товар (workload), в който е внедрен. Само откраднатите ключове на доставчици позволяват на киберпрестъпник да изпълнява модели за сметка на жертвата — злоупотреба, известна като LLMjacking.

Как ключът достига до облачния акаунт

LiteLLM позволява на администратора да създаде транзитна крайна точка (pass-through endpoint) — маршрут, който пренасочва заявки към произволен URL адрес, избран от администратора.

Целевият URL адрес не се проверява спрямо частни диапазони от адреси, localhost или адреси за облачни метаданни. Следователно администраторът може да насочи маршрут към услугата за метаданни на инстанцията и да прочете върнатите IAM идентификационни данни.

Преминаването към IMDSv2 не спира това. Документацията на LiteLLM посочва, че всеки хедър, изпратен с префикс x-pass-, се предава към целта с премахнат префикс, като Wiz използва това, за да изпрати хедърите, изисквани от IMDSv2.

Няма източници, съобщаващи някой да е извършил това срещу реална система. Това е демонстрация и първо изисква администраторски достъп.

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

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

Недостатъкът в защитните бариери и оспорваната сериозност

Единственият дефект за изпълнение на код в доклада на Wiz е CVE-2026-59821, като изследователите и поддържащите проекта го описват по много различен начин.

Wiz го нарича изпълнение на код след автентификация на ниво root и показва тест, връщащ uid=0(root) в контейнера на портала. Бюлетинът на LiteLLM за същата CVE уязвимост я оценява като ниска (2.1 по скалата CVSS), описвайки я като дефект, който изисква акаунт с високи привилегии.

И двете страни описват едно и също поведение. Преди 1.82.0-stable крайните точки, които създават и обновяват персонализирани защитни бариери за код, пропускаха проверките за шаблони и изолираната среда, прилагани от тестовата крайна точка, така че всеки, който можеше да ги достигне, можеше да изпрати Python код, който да се изпълни в контейнера.

Бюлетинът добавя, че инсталация без главен ключ е третирала заявителите като прокси администратори, което именно е направило тези крайни точки достъпни.

Докладът на Wiz посочва, че след 1.82.0 атакуващ с ключа по подразбиране е можел да изпълнява код само в изолирана среда. Собствените записи на LiteLLM не подкрепят това за всяка версия.

Отделен бюлетин, публикуван през май — CVE-2026-40217, гласи, че изолираната среда е можело да бъде преодоляна чрез техники с байткод от изпълнението на код в прокси процеса, за който бюлетинът отбелязва, че се изпълнява като root в Docker образа по подразбиране.

Той засяга версии от 1.81.8 до 1.83.10 (без нея), а достигането до крайната точка изисква прокси администраторски данни. Главният ключ е точно такъв идентификатор.

И двата дефекта, съобщени от Wiz, бяха коригирани месеци преди доклада му от 9 септември — през февруари и април, а техните CVE бяха публикувани през юли.

Отделно: Уязвимостите в LiteLLM, които вече се експлоатират

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

CISA добави една уязвимост в LiteLLM към своя каталог с известни експлоатирани уязвимости (Known Exploited Vulnerabilities) на 2 септември. CVE-2026-59822 (CVSS оценка: 8.8), също открита от Wiz, позволява на неавтентифициран атакуващ да отвори валидна MCP сесия, използвайки какъвто и да е Bearer токен, включително такъв с дължина от един символ. Федералните граждански агенции разполагат със срок до 16 септември да отстранят уязвимостта.

Wiz забеляза използването ѝ срещу своите системи-примамки, започвайки от 7 юли, в заявки, съдържащи едносимволни токени за сондиране на крайните точки за списъци с модели. Wiz не описва друга нейна употреба.

Тази уязвимост не достига до векторите за изпълнение на код или до идентификационните данни по-горе. Wiz заявява, че тя „позволява единствено достъп до MCP сървъра“. До какво може да достигне зависи от това към кои сървъри за инструменти се е свързала дадена организация.

Уязвимостта в LiteLLM, която киберпрестъпниците са използвали за изпълнение на код, е различна. CVE-2026-42271 (CVSS оценка: 8.7) позволяваше на всеки автентифициран потребител да изпълнява команди на хоста през две тестови MCP крайни точки, а Horizon3.ai съобщи през юни, че тя може да бъде свързана във верига с уязвимост в хедъра на хоста на Starlette (CVE-2026-48710), за да се постигне същото без никакви идентификационни данни.

Системите-примамки на Wiz записаха използването на тази уязвимост за инсталиране на софтуер за копаене на криптовалута.

Microsoft публикува случай през август, при който атакуващите са изпълнявали команди в процеса на LiteLLM шлюза, прочели са средата на контейнера за основния ключ (master key), ключовете на доставчиците и низа за връзка с базата данни, а след това са използвали този низ, за да получат достъп до лежащата отдолу база данни PostgreSQL и да копират записи от таблиците за модели и виртуални ключове на LiteLLM.

Microsoft оценява с висока увереност, че атакуващите са получили достъп през изложения шлюз и заявява, че точката на вход съответства на веригата от уязвимости CVE-2026-42271 и CVE-2026-48710. „Третирайте AI шлюзовете като хранилища за секрети от ниво Tier-0“, заяви компанията.

Какво да направите сега

Обновяването до версия 1.84.0 или по-нова покрива всяка уязвимост от таблицата. Диапазоните от версии са както е посочено в бюлетините за сигурност.

1. Променете основния ключ (master key) от sk-1234 на дълга случайна стойност. Това не изисква обновяване. Първо проверете дали е зададен отделен salt ключ, тъй като процедурата по ротация се различава и използването на грешния може да направи съхранените идентификационни данни нечетими.
2. Обновете до 1.84.0 или по-нова версия. Това издание е над коригираната версия на всяка уязвимост в таблицата.
3. Ако все още не можете да обновите, блокирайте /mcp/ и двете MCP тестови крайни точки, POST /mcp-rest/test/connection и POST /mcp-rest/test/tools/list, на вашия reverse proxy или API шлюз.
4. Също така блокирайте POST /guardrails/test_custom_code и ограничете POST /guardrails и PUT /guardrails/{guardrail_id} само за администратори. Това са временните решения в официалните бюлетини за сигурност на LiteLLM.
5. Прегледайте транзитните крайни точки (pass-through endpoints) на шлюза, ограничете изходящия мрежов достъп на контейнера и предоставете на работното натоварване най-ограничената cloud IAM роля, с която то може да работи.
6. Ако смятате, че атакуващ е имал достъп, прегледайте списъка с guardrails за записи, които не сте създали вие, и рестартирайте процеса, за да изчистите кода, съхраняван в паметта, след което извършете ротация на ключовете на доставчиците, основния ключ и идентификационните данни за базата данни. Обновяването не премахва нито guardrail, регистриран от атакуващ, нито SSH ключ, добавен от него.

Няма корекция за сигурност за транзитния маршрут (pass-through) към метаданните на екземпляра, тъй като LiteLLM не го третира като уязвимост. Ограниченията на изходящата мрежа и тесните IAM роли са единствените налични механизми за контрол.

Никой източник не посочва как да проверите дали MCP или pass-through маршрутите са активирани на шлюз, който сте наследили. Заявките за търсене (hunting queries) на Microsoft откриват експлоатация, а не конфигурация.