На проверке CVE-2026-42208: SQL-инъекция в LiteLLM — эксплуатация через Authorization header

Поднимаю LiteLLM в Docker-стендах последний год - удобный прокси для роутинга запросов к OpenAI и Anthropic через единый endpoint, когда тестируешь AI-обвязку заказчика на пентесте. Когда 24 апреля 2026-го advisory всплыл в GitHub Advisory Database, первым делом отправил curl с одинарной кавычкой в Authorization: Bearer на свой стенд с v1.82.x. Ответ - HTTP 500 с фрагментом SQL-ошибки PostgreSQL. Одна кавычка. Один запрос. Ноль аутентификации.

CVE-2026-42208 - pre-auth SQL-инъекция в LiteLLM AI Gateway, CVSS 4.0: 9.3 (CRITICAL), EPSS 0.89 (top 1% по вероятности эксплуатации), включена в CISA KEV 8 мая. Ниже - разбор от корневой причины до рабочих payload'ов, цепочка атаки до RCE и конкретные индикаторы компрометации.

Бизнес-логика атаки: зачем ломать LiteLLM AI Gateway​

LiteLLM - open-source прокси-сервер (AI Gateway) с 22 000+ звёзд на GitHub. Единая точка входа к API десятков LLM-провайдеров: OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Vertex AI. Оператор конфигурирует модели, виртуальные API-ключи, бюджеты и учётные данные провайдеров через админку. Клиент отправляет Authorization: Bearer sk-... - прокси проверяет ключ, применяет rate limit и маршрутизирует запрос к upstream-модели.

Для атакующего LiteLLM AI Gateway - jackpot. Три причины:

Первая - концентрация секретов. В одной PostgreSQL-базе лежат API-ключи OpenAI с пятизначными лимитами расходов, ключи Anthropic с правами администратора workspace, IAM-креды AWS Bedrock. Всё, что оператор доверил прокси. По масштабу последствий это ближе к компрометации облачного аккаунта, чем к типичной SQLi в веб-приложении.

Вторая - промпты и ответы. LiteLLM по умолчанию логирует запросы и ответы моделей. В логах - клиентский PII, внутренние документы, код, иногда креды, вставленные в copilot-сессии.

Третья - сетевая доступность. В продакшене LiteLLM часто разворачивают на публичном IP, чтобы внутренние сервисы и партнёрские интеграции могли обращаться к прокси. Порт 4000 торчит наружу без WAF.

Компрометация gateway - это одновременно credential theft, prompt exfiltration и lateral movement в стек приложения. Kill chain по MITRE ATT&CK: Vulnerability Scanning (T1595.002, Reconnaissance) → Exploit Public-Facing Application (T1190, Initial Access) → Databases (T1213.006, Collection) → Credentials In Files (T1552.001, Credential Access) → Cloud Accounts (T1078.004, Defense Evasion / Persistence / Privilege Escalation / Initial Access).

Корень уязвимости: конкатенация Bearer-токена в SQL-запрос​

В затронутых версиях LiteLLM (от 1.81.16 до 1.83.6 включительно) значение из заголовка Authorization: Bearer подставлялось в SQL-запрос к таблице LiteLLM_VerificationToken через строковую интерполяцию - без параметризации. По описанию NVD: «a database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter».

Уязвимый паттерн (упрощённо, на основе описания NVD):

SELECT * FROM "LiteLLM_VerificationToken"
WHERE token = '{bearer_token}'

Если bearer_token содержит ' UNION SELECT ...--, одинарная кавычка разрывает строковый литерал и позволяет дописать произвольный SQL. CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) - классика из OWASP A03:2021 Injection (в OWASP Top 10 2025 - A05).

Критический нюанс: SQL-инъекция через Authorization header срабатывает до принятия решения об аутентификации. Запрос к БД выполняется в error-handling path прокси, когда Bearer-токен не проходит первичную валидацию. Атакующему не нужны ни валидный API-ключ, ни обход rate limiter - хватит TCP-доступа к порту прокси.

Конкатенация пользовательского ввода в SQL - баг уровня 2012 года. И он прошёл через десятки релизов проекта с 22 000 звёзд.

Фикс в v1.83.7 заменяет конкатенацию на параметризованный запрос. Advisory опубликован в GitHub Advisory Database.

Предусловия и ограничения эксплуатации CVE-2026-42208​

Прежде чем тянуться к sqlmap - проверь контекст.

Работает если:

• LiteLLM версии v1.81.16 - v1.83.6 (PyPI-пакет litellm в этом диапазоне)
• Прокси использует PostgreSQL-бэкенд (стандарт для proxy-режима с хранением ключей)
• Есть сетевой доступ к порту LiteLLM (по умолчанию 4000)
• Нет WAF на уровне L7, фильтрующего SQL-синтаксис в заголовках

Не работает если:

• Версия ≥ v1.83.7 (параметризованный запрос)
• Прокси запущен без БД (режим litellm --model gpt-4 без PostgreSQL - ключи не хранятся, уязвимый путь не достигается)
• Установлен disable_error_logs: true в general_settings - убирает error-handling path, через который input попадает в уязвимый запрос (vendor-рекомендованный workaround)
• Перед прокси стоит reverse proxy с правилом, блокирующим SQL-синтаксис в Authorization

Требования к стенду для воспроизведения:

• Docker + docker-compose, PostgreSQL 13+, 2 ГБ RAM
• LiteLLM v1.82.x (конкретный тег из Docker Hub, например ghcr.io/berriai/litellm:main-v1.82.0)
• На атакующей стороне: curl, Python 3.x, опционально sqlmap

[Применимо: внешний пентест, любая ОС на стороне атакующего, PostgreSQL-бэкенд на стороне цели]

Fingerprinting уязвимого экземпляра LiteLLM​

Перед эксплуатацией - разведка. LiteLLM по умолчанию отдаёт информацию на нескольких эндпоинтах без аутентификации.

Запрос GET /health вернёт JSON со статусом и версией прокси. Версия в ответе - первая точка проверки: диапазон 1.81.16 - 1.83.6 означает потенциальную уязвимость LiteLLM proxy сервера.

Запрос GET /v1/models покажет список доступных моделей и подтвердит, что перед тобой именно LiteLLM, а не generic OpenAI endpoint. Модели с префиксами разных провайдеров (gpt-4, claude-3, bedrock/*) - маркер мультипровайдерного gateway. В БД такого инстанса с высокой вероятностью лежат ключи от каждого провайдера.

Для массового сканирования уже есть Nuclei-шаблон http/cves/2026/CVE-2026-42208.yaml в официальном репозитории projectdiscovery/nuclei-templates. Запуск: nuclei -t http/cves/2026/CVE-2026-42208.yaml -l targets.txt.

Ручная проверка: curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer '" http://target:4000/chat/completions -X POST -d '{}'. HTTP 500 с SQL-ошибкой в теле - маркер неаутентифицированной SQLi LiteLLM. HTTP 401 без SQL-трейса может означать патч, WAF-блокировку до прокси либо неверный формат запроса - тогда перепроверяй через /health endpoint.

Эксплуатация CVE-2026-42208: payload'ы и цепочка атаки​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

, но предварительно убедитесь, что точка инъекции обнаруживается без этого флага. Маркер [I] в значении заголовка указывает sqlmap точку инъекции; в некоторых shell-окружениях [/I] может быть раскрыт как glob - оборачивайте аргумент одинарными кавычками.

Цепочка с CVE-2026-42203: от SQLi до RCE в контейнере​

SQL-инъекция через Authorization header даёт чтение и модификацию БД. Но если цель - выполнение кода внутри контейнера LiteLLM, есть вторая уязвимость в том же диапазоне версий.

CVE-2026-42203 (CVSS 8.6, HIGH) - Server-Side Template Injection в эндпоинте POST /prompts/test. По данным NVD: эндпоинт принимает пользовательские prompt-шаблоны и рендерит их без sandboxing. Crafted-шаблон выполняет произвольный код в процессе LiteLLM Proxy. CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine) и CWE-94 (Code Injection). Затронуты версии от 1.80.5 до 1.83.6.

А вот ключевой нюанс: CVE-2026-42203 требует аутентификации - нужен валидный прокси API-ключ. Но этот ключ мы только что вытянули через CVE-2026-42208.

Гипотетическая цепочка атаки (на основе анализа описаний обеих CVE):

1. Pre-auth SQLi (CVE-2026-42208) → вытаскиваем виртуальный API-ключ или master key из LiteLLM_VerificationToken
2. Credential replay → используем украденный ключ для аутентификации на прокси. Никакого второго фактора, никакой привязки ключа к IP - LiteLLM по умолчанию не привязывает ключи к source
3. Auth'd SSTI → RCE (CVE-2026-42203) → отправляем crafted-шаблон на POST /prompts/test, код выполняется в контейнере

Результат: неаутентифицированный атакующий из интернета, два HTTP-запроса - и выполнение кода внутри контейнера, который держит все ключи, промпты и ответы AI-стека. Обе уязвимости исправлены в v1.83.7.

CISA Vulnrichment классифицирует CVE-2026-42208 как Exploitation: active, Automatable: yes, Technical Impact: total с решением Act (патчить немедленно). Technical Impact у обеих уязвимостей - total; разница в приоритете обусловлена статусом эксплуатации и автоматизируемостью, а не масштабом ущерба. CVE-2026-42203 - Exploitation: none, Automatable: no, Technical Impact: total с решением Track. EPSS подтверждает приоритеты: 0.8942 для SQLi vs 0.0037 для SSTI - атакующие фокусируются на pre-auth примитиве.

Вероятный сценарий эксплуатации​

Advisory индексирован в GitHub Advisory Database 24 апреля 2026. Repository-level advisory от мейнтейнера был опубликован. С EPSS 0.89 и включением в CISA KEV вероятность быстрой эксплуатации после disclosure - крайне высокая.

Фаза 1: перечисление схемы. Атакующий шлёт POST /chat/completions с payload'ами в Authorization. Первые запросы - к предполагаемым высокоценным таблицам (например, LiteLLM_VerificationToken, подтверждённая в описании CVE, а также таблицы с upstream-ключами и конфигурацией - конкретные имена атакующий берёт из открытой Prisma-схемы проекта). Затем серия запросов для перебора количества столбцов (UNION SELECT api_key FROM ..., затем api_key,NULL, api_key,NULL,NULL и т.д.).

Фаза 2: ротация IP. Для обхода per-IP rate limit атакующий ротирует исходящие IP внутри одной подсети, повторяя набор payload'ов.

Особенность этой уязвимости - атакующему не нужна фаза information_schema.tables: Prisma-схема LiteLLM доступна в открытом репозитории проекта. Имена таблиц и столбцов известны заранее. Если UNION-перебор не даёт результатов (несовпадение количества столбцов или пустые таблицы), типичный fallback - деградация до тавтологии (OR 1=1--).

Детекция: IoC и сигнатуры для выявления AI Gateway exploit​

Запросы с SQL-инъекцией в Authorization выглядят валидно на уровне протокола - стандартный POST с Bearer-токеном. Детектить нужно на уровне содержимого заголовка.

Сигнатуры эксплуатации:

Bearer-токен с одинарной кавычкой, за которой SQL-синтаксис (UNION SELECT, OR 1=1, pg_sleep, WAITFOR DELAY). User-Agent с Python HTTP-библиотеками (aiohttp, requests, httpx) при обращении к API-эндпоинтам.

Что мониторить в логах:

1. Заголовок Authorization с нехарактерным содержимым. Валидные LiteLLM-ключи начинаются с sk-. Токен без префикса sk- и с SQL-ключевыми словами - exploit.
2. HTTP 500 на эндпоинтах /chat/completions, /v1/models при наличии Bearer - error-handling path, через который работает инъекция.
3. Множественные POST к одному API-роуту с вариациями в Authorization за короткий интервал - перебор столбцов для UNION.

WAF-правило: два условия одновременно: (1) Bearer-токен не начинается с sk- - запрос на уязвимом code path; (2) токен содержит SQL-синтаксис (одинарные кавычки + SELECT/UNION/OR/pg_sleep). По отдельности каждое условие даёт false positives (опечатки в ключах), вместе - точная сигнатура exploit'а.

Проверка PostgreSQL: если прокси был доступен из недоверенной сети на уязвимой версии - проверьте логи PostgreSQL на аномальные UNION/SELECT в контексте обращений к таблицам LiteLLM_VerificationToken, litellm_credentials, litellm_config.

Патч LiteLLM SQL injection: чеклист для ops-команды​

1. Обновить LiteLLM до v1.83.10-stable (Release v1.83.10-stable · BerriAI/litellm). Минимально - до v1.83.7, но vendor рекомендует 1.83.10 как проверенный stable-релиз.
2. Если обновление невозможно прямо сейчас - установить disable_error_logs: true в секции general_settings конфигурации. Убирает error-handling path. Временная мера, не заменяет патч.
3. Считать скомпрометированным любой интернет-доступный инстанс на версиях 1.81.16 - 1.83.6 (диапазон CVE-2026-42208) за период экспозиции. Ротировать: все ключи провайдеров (OpenAI, Anthropic, Bedrock IAM), все виртуальные API-ключи LiteLLM, master key прокси.
4. Проверить PostgreSQL-логи на аномальные запросы. Искать UNION/SELECT в контексте обращений к таблице LiteLLM_VerificationToken и другим таблицам схемы LiteLLM.
5. Убрать прокси за reverse proxy (nginx, Envoy) с WAF-правилом, блокирующим SQL-синтаксис в заголовке Authorization - защита от аналогичных SQLi без аутентификации в API-слое на будущее.
6. Проверить на CVE-2026-42203. Версии от 1.80.5 до 1.83.6 уязвимы к SSTI → RCE на POST /prompts/test при наличии валидного API-ключа. Фикс тот же - v1.83.7+.

Уязвимость добавлена в CISA KEV 8 мая 2026 года с дедлайном устранения 11 мая - трёхдневное окно. OWASP A06:2021 (Vulnerable and Outdated Components) напоминает: если уязвимая версия до сих пор в проде, проблема не только в конкретном CVE, а в процессе управления зависимостями.



Вот уже несколько месяцев наблюдаю один и тот же паттерн: AI-инфраструктура, которую строят ML-инженеры, повторяет ошибки веб-разработки десятилетней давности. Конкатенация пользовательского ввода в SQL - баг уровня 2012 года. И он прошёл через десятки релизов проекта с 22 000 звёзд на GitHub. Проблема не в том, что LiteLLM написан плохо. Проблема в том, что AI middleware воспринимается как «внутренний сервис», которому прощают отсутствие security review. ML-команды фокусируются на prompt engineering и fine-tuning, а security debt копится в прокси-слое - том самом, через который текут все ключи и все промпты.

Короткое окно от disclosure до exploitation - не исключение, а новая норма. Для пентестера вывод простой: если в скоупе есть AI-компоненты - проверяй middleware первым, а не последним. Модели не ломают. Ломают прокси перед ними. На HackerLab есть лаба, где подобную цепочку нужно собрать от первого SELECT до шелла без подсказок.