LiteLLM — популярний open-source шлюз між застосунками та провайдерами мовних моделей — опинився в центрі серії інцидентів безпеки. За даними Wiz Research, у лютому 2026 року майже кожен десятий із виявлених в інтернеті серверів LiteLLM приймав sk-1234 — приклад адміністративного ключа з офіційного посібника з установлення. Цей ключ відкриває доступ до всіх API-ключів провайдерів моделей, що зберігаються на сервері, а за певних умов — і до хмарних IAM-облікових даних. CISA вже внесла одну з вразливостей LiteLLM до каталогу відомих експлуатованих вразливостей, а Microsoft і Wiz зафіксували реальні атаки з установленням криптомайнерів і крадіжкою секретів. Організаціям, які використовують LiteLLM, необхідно негайно змінити майстер-ключ і оновитися до версії 1.84.0 або вище.
Масштаб проблеми з дефолтним ключем
За даними Wiz, у лютому 2026 року в Shodan було виявлено 3 074 публічно доступних шлюзи LiteLLM. Із них 294 приймали ключ sk-1234. При цьому в 191 сервера майстер-ключ взагалі не було задано — вони приймали будь-який запит з правами адміністратора. Решта використовували значення з посібника з установлення без змін. Повторне сканування в серпні виявило понад 85 000 екземплярів, однак Wiz зазначає, що більшість із них, імовірно, є пастками (honeypot) або тестовими системами, тому напряму порівнювати ці цифри не можна.
Майстер-ключ у LiteLLM виконує подвійну функцію: він одночасно є обліковими даними адміністратора і перемикачем, який активує автентифікацію. До версії 1.82.0-stable шлюз, запущений без майстер-ключа, надавав кожному вхідному запиту повні права адміністратора. Адміністратор шлюзу отримує доступ до всіх API-ключів провайдерів, бачить усі запити та відповіді, що проходять через нього, а також може під’єднуватися до внутрішніх інструментів через Model Context Protocol (MCP). Викрадені ключі провайдерів дають змогу зловмиснику запускати навантаження моделей коштом жертви — атака, відома як LLMjacking.
Карта вразливостей: п’ять CVE та їхній взаємозв’язок
Навколо LiteLLM сформувався цілий кластер вразливостей. Раніше ми вже писали про додавання низки вразливостей LiteLLM до каталогу CISA KEV. Розглянемо повну картину.
CVE-2026-59822 (CVSS 8.8, High) — обхід автентифікації MCP. Дозволяє неавтентифікованому зловмиснику відкрити валідну MCP-сесію, використовуючи довільний Bearer-токен, зокрема завдовжки в один символ. Стосується версій до 1.84.0. Згідно з бюлетенем безпеки LiteLLM, виправлена у 1.84.0. CISA додала цю вразливість до каталогу KEV 2 вересня з дедлайном для федеральних агентств до 16 вересня. За даними Wiz, експлуатація спостерігалася в їхніх пастках починаючи з 7 липня — запити з однолітерними токенами зондували ендпоінти переліку моделей. Wiz уточнює, що ця вразливість «дозволяє лише доступ до MCP-сервера», а реальна шкода залежить від під’єднаних інструментів.
CVE-2026-42271 (CVSS 8.7, High) — виконання команд через тестові MCP-ендпоінти. Згідно з бюлетенем безпеки GitHub, стосується версій ≥1.74.2 і <1.83.7. Дозволяє автентифікованому користувачу з валідним API-ключем проксі виконувати команди через MCP stdio тестові ендпоінти. Виправлена у 1.83.7. Саме ця вразливість стала основним вектором реальних атак.
CVE-2026-48710 (CVSS 6.5) — обхід перевірки Host-заголовка в Starlette (≤1.0.0). Згідно з бюлетенем безпеки, спотворені Host-заголовки змушують request.url.path відрізнятися від маршрутизованого шляху, обходячи перевірки безпеки, що ґрунтуються на шляхах. Виправлена в Starlette 1.0.1. Horizon3.ai продемонструвала, що ця вразливість у зв’язці з CVE-2026-42271 дає змогу виконувати команди без автентифікації.
CVE-2026-59821 (CVSS 2.1, Low за оцінкою LiteLLM CNA) — обхід перевірок безпеки коду в ендпоінтах створення та оновлення користувацьких guardrails. Стосується версій до 1.82.0-stable. Згідно з бюлетенем безпеки, потребує привілейованого облікового запису, хоча розгортання без налаштованого майстер-ключа обробляли тих, хто викликає, як адміністраторів. Wiz описує ту саму поведінку як виконання коду на рівні root усередині контейнера шлюзу — розбіжність в оцінці серйозності між дослідниками та мейнтейнерами.
CVE-2026-40217 (CVSS 5.9, Moderate) — вихід із пісочниці в користувацьких guardrails через техніки роботи з байткодом. Згідно з бюлетенем безпеки, стосується версій ≥1.81.8 і <1.83.10, хоча в описі бюлетеня вказано версію виправлення 1.83.11 — внутрішня суперечність. Процес проксі в Docker-образі за замовчуванням працює від root. Для експлуатації потрібні облікові дані адміністратора проксі, тобто майстер-ключ.
Шлях до хмарних облікових даних
Окремої уваги заслуговує механізм, що не має CVE. За даними Wiz, LiteLLM дозволяє адміністратору створювати скрізні (pass-through) ендпоінти, які перенаправляють запити на довільні URL. Цільовий URL не перевіряється на належність до приватних діапазонів адрес, localhost чи адрес метаданих хмари. Адміністратор може спрямувати маршрут на сервіс метаданих екземпляра і отримати IAM-облікові дані. Перехід на IMDSv2 не блокує цей шлях: LiteLLM документує, що заголовки з префіксом x-pass- передаються цільовому серверу без префікса, що дозволяє надіслати заголовки, яких вимагає IMDSv2. Wiz зазначає, що ця функція «працює як задумано», оскільки модель загроз LiteLLM вважає адміністраторів довіреними. Патча немає і не планується.
Реальні атаки: від криптомайнінгу до крадіжки баз даних
Вразливості LiteLLM активно експлуатуються. За даними Wiz, у їхніх пастках зафіксовано експлуатацію CVE-2026-42271 для встановлення криптомайнера. Microsoft опублікувала в серпні опис інциденту, в якому зловмисники виконали команди всередині процесу шлюза LiteLLM, отримали з оточення контейнера майстер-ключ, ключі провайдерів і рядок підключення до бази даних, а потім використали його для доступу до PostgreSQL і копіювання записів із таблиць моделей і віртуальних ключів. Microsoft з високим ступенем упевненості оцінює, що точка входу відповідає ланцюжку CVE-2026-42271 і CVE-2026-48710. Компанія рекомендує «ставитися до AI-шлюзів як до сховищ секретів рівня Tier-0».
Індикатори компрометації
За даними Wiz, у кампанії з криптомайнером використовувалися такі індикатори:
- IP-адреси:
185.62.1[.]8,185.84.98[.]85,94.26.106[.]29 - URL завантаження:
http://185.62.1.8/mon/mon.zip - Шлях установлення майнера:
/tmp/.dbus-cache/gmon - Домен пулу:
pool.hashvault[.]pro
Пріоритизація реагування
Серед усіх описаних проблем найбільшу безпосередню загрозу становлять CVE-2026-59822 і CVE-2026-42271 — обидві мають підтверджену експлуатацію і стосуються MCP-ендпоінтів, доступних з інтернету. Шлях через pass-through до метаданих хмари потребує попереднього отримання адміністративного доступу і є постексплуатаційним вектором, а не самостійною точкою входу.
Рекомендації
- Негайно змініть майстер-ключ з
sk-1234на довге випадкове значення. Це не потребує оновлення версії. Перед зміною перевірте, чи задано окремий ключ солі — процедура ротації відрізняється, і помилка може зробити збережені облікові дані нечитаними. - Оновіться до версії 1.84.0 або вище. Ця версія знаходиться вище порога виправлення для всіх перелічених вразливостей LiteLLM, включно з CVE-2026-40217, для якої в бюлетені безпеки є внутрішня розбіжність між 1.83.10 і 1.83.11.
- Якщо оновлення неможливе негайно, заблокуйте на рівні зворотного проксі або API-шлюзу:
/mcp/,POST /mcp-rest/test/connection,POST /mcp-rest/test/tools/list,POST /guardrails/test_custom_code. ОбмежтеPOST /guardrailsіPUT /guardrails/{guardrail_id}лише адміністраторам. - Обмежте вихідний мережевий доступ контейнера і призначте робочому навантаженню мінімально необхідну хмарну IAM-роль — це єдиний захист від маршруту до метаданих екземпляра через pass-through.
- За підозри на компрометацію: перевірте список guardrails на сторонні записи, перезапустіть процес для очищення коду в пам’яті, а потім ротують ключі провайдерів, майстер-ключ і облікові дані бази даних. Оновлення версії не видаляє ані зареєстровані зловмисником guardrails, ані додані SSH-ключі.
Шлюз LiteLLM, доступний з інтернету з дефолтним ключем sk-1234, фактично є відкритим сховищем секретів. Зміна майстер-ключа — дія, яка займає хвилину і закриває більшість описаних векторів атак без оновлення версії. Оновлення до 1.84.0 закриває решту. Організаціям, які виявили у себе LiteLLM з дефолтною конфігурацією, слід виходити з припущення про можливу компрометацію та провести ротацію всіх пов’язаних секретів.
