Внедряването на LiteLLM може да разкрие много повече от разходите за изкуствен интелект на дадена организация. Новооткрити слабости в портала с отворен код биха могли да позволят на атакуващи да изпълняват код като root вътре в контейнер, да достигнат до свързани инструменти и да извлекат идентификационни данни за облака, които отварят път към по-широка среда.
Рискът е сериозен, когато услугата е достъпна от интернет или запазва примерния си главен ключ (master key). Порталът се намира между приложенията, доставчиците на модели, вътрешните данни и автоматизацията, така че неговото компрометиране може да превърне една пренебрегната услуга в централна точка на отказ.
Изследователи от Wiz.io идентифицираха проблемите, докато анализираха публични инсталации на LiteLLM. Тяхното сканиране на 3 074 инсталации с достъп до интернет установи, че 294 от тях (или 9,6%) са приемали главния ключ по подразбиране или изобщо не са имали включена автентификация.
От Wiz.io посочват в доклад, споделен с Cyber Security News (CSN), че заобикалянето на автентификацията в MCP (проследявано като CVE-2026-59822) е било наблюдавано в реални атаки чрез техните системи тип „примамка“ (honeypots).
CISA добави уязвимостта в своя каталог с познати експлоатирани уязвимости (Known Exploited Vulnerabilities) на 2 септември, увеличавайки спешността за мерки от страна на организациите с достъпни инстанции.
Слабости в LiteLLM позволяват на атакуващите да изпълняват код
CVE-2026-59821 засяга функцията Custom Code Guardrails на LiteLLM, която позволява на администраторите да предоставят политики на Python, изпълняващи се около заявките към моделите.
Преди отстраняването на проблема, крайната точка, използвана за регистриране на защитна стена (guardrail), не е прилагала проверките за безопасност, налични в тестовия интерфейс, което е позволявало на подадения код да се изпълни незабавно.
Резултатът може да бъде изпълнение на команди на ниво root в контейнера на LiteLLM, когато киберпрестъпник разполага с администраторски достъп.
Този достъп може да бъде наличен там, където липсва автентификация, главният ключ по подразбиране не е променен или се експлоатира друга административна слабост. Читателите могат да я сравнят с по-ранната уязвимост в администраторския API на LiteLLM, която засягаше контролите за конфигурация.
Дистанционното изпълнение на код (RCE) изисква автентикиран администратор и не може да бъде достигнато единствено чрез заобикалянето на MCP. Несигурните настройки за внедряване обаче могат да премахнат тази бариера.
Във версии преди 1.82.0 непроменените данни за достъп по подразбиране могат да направят пътя за изпълнение на код практически достъпен още преди нормалната автентификация.
Проблемът в MCP създава различна точка на вход. Невалиден Bearer токен може да установи валидна сесия със свързан MCP сървър, което потенциално позволява на нападателя да използва наличните инструменти за бази данни, хранилища, файлови системи или работни процеси.
Това се различава от експлоатацията на LiteLLM RCE в реална среда, която включваше друга верига от уязвимости. LiteLLM коригира уязвимостта в guardrail компонента във версия 1.82.0 чрез налагане на администраторска роля и прилагане на защити тип изолирана среда по време на регистрацията.
По-късно беше отстранено и заобикалянето на автентификацията в MCP във версия 1.84.0. Организациите трябва да идентифицират използваната версия, да инсталират корекции за сигурност своевременно и да проверят за изложени по-стари контейнери или тестови инстанции.
Облачните ключове са под риск
Констатациите показват защо порталите за изкуствен интелект изискват същата защита, каквато се предоставя на други привилегировани облачни услуги. LiteLLM може да съхранява API ключове на доставчици и да комуникира с вътрешни системи, докато неговата идентичност на работното натоварване (workload identity) може да носи разрешения за извикване на модели, четене на тайни или взаимодействие с други облачни услуги.
Функцията за препращане (pass-through) може да пренасочва заявки към определно от администратора местоназначение, без да проверява дали то е вътрешен адрес или услуга за метаданни в облака. С администраторски достъп атакуващ би могъл да я използва, за да получи временни AWS IAM данни за достъп.
Това не е самостоятелна уязвимост, но става опасна, когато контролът на достъпа се провали. Маршрутът за актуализиране на конфигурацията, контролиращ настройките за препращане, също нямаше проверка за администратор преди версия 1.83.0 – отделен проблем, проследяван като CVE-2026-35029.
Този модел се вижда и при кражбата на данни за достъп в инфраструктура за изкуствен интелект, където публично достъпните портали могат да осигурят на атакуващите достъп до тайни, персистентност и злоупотреба с ресурси.
Администраторите трябва да заменят примерните данни за достъп със силен, уникален главен ключ и да прегледат защитните стени (guardrails) за неочаквани записи. Рестартирането на процеса може да изчисти кода, запазен в паметта.
Те трябва да одитират настройките за препращане, да ограничат изходящия трафик на контейнера и да приложат IAM разрешения с най-малки привилегии към идентичностите на работното натоварване.
Премахнете интерфейсите за управление от публичния интернет и ограничете достъпа само до доверени мрежи и автентикирани администратори.
Завъртете (rotate) API ключовете на доставчиците и облачните данни за достъп, ако е имало достъп до уязвима публична инстанция, след което прегледайте логовете за съмнителна административна дейност и необичайни изходящи заявки.
Рискът във веригата за доставки на LiteLLM също показва защо порталите се нуждаят от внимателна конфигурация, управление на идентичността и контрол на актуализациите.
Показатели за компрометиране (IoCs):-
| Тип | Показател | Описание |
|---|---|---|
| Default credential | sk-1234 | Главен ключ на LiteLLM по подразбиране, приеман от уязвими инсталации |
| HTTP endpoint | /mcp/ | MCP крайна точка, засегната от проблема със заобикаляне на автентификацията |
| HTTP header value | Authorization: Bearer a | Минимална стойност на Bearer токен, използвана за демонстрация на установяване на MCP сесия |
| HTTP endpoint | /guardrails | Крайна точка за регистрация на guardrail, свързана с изпълнение на персонализиран код |
| HTTP endpoint | /config/pass_through_endpoint | Крайна точка, използвана за конфигуриране на маршрути за препращане на заявки |
| URL | http://169.254.169.254/latest/ | Целева услуга за метаданни на AWS инстанция, използвана в демонстрацията за кражба на данни за достъп в облака |
| File name | user_api_key_auth_mcp.py | Изходен файл на манипулатора за автентификация в LiteLLM MCP |
| File name | guardrail_endpoints.py | Изходен файл за guardrail крайна точка в LiteLLM |
| File name | custom_code_guardrail.py | Изходен файл за guardrail с персонализиран код в LiteLLM |
| File name | pass_through_endpoints.py | Изходен файл за крайна точка за препращане в LiteLLM |
Забележка: IP адресите и домейните са умишлено дезактивирани (напр. [.]), за да се предотврати случайно решаване или създаване на хипервръзки. Възстановете ги само в рамките на контролирани платформи за анализ на заплахи като MISP, VirusTotal или вашата SIEM система.
Поддържайте вашия SOC център актуализиран за активен зловреден код и фишинг в рамките на 24 часа от появата им. Изпробвайте ANYRUN, за да предотвратите инциденти с ранно откриване.