vLLM: неограниченная кардинальность меток Prometheus через HTTP-методы — DoS без аутентификации (CVE-2026-105759)
В vLLM до версии 0.30.0 middleware track_http_metrics в Rust-фронтенде записывает сырой токен HTTP-метода как метку Prometheus. Неаутентифицированный атакующий может отправлять произвольные уникальные методы на незащищённые маршруты, такие как /tokenize, что ведёт к неограниченному росту числа меток, потреблению памяти и разрастанию ответа /metrics вплоть до отказа в обслуживании. Критичность — CVSS 5.9 (MEDIUM).
Подробности
Проблема затрагивает vLLM в версиях до 0.30.0 и связана с компонентом Rust-фронтенда — middleware track_http_metrics. Этот middleware фиксирует сырой токен HTTP-метода как значение метки (label) для Prometheus-метрик при обработке запросов, попадающих на зарегистрированные маршруты. HTTP-метод в запросе — это произвольная строка, которую клиент передаёт в стартовой строке запроса. Middleware не ограничивает множество допустимых значений, поэтому атакующий может отправлять запросы с произвольными уникальными методами (например, METHOD_A, METHOD_B и так далее) на маршруты, не требующие аутентификации, — в описании CVE в качестве примера указан /tokenize. Каждый новый токен метода приводит к тому, что функция Family::get_or_create библиотеки Prometheus навсегда создаёт новый набор меток для счётчика (counter) и гистограммы (histogram). Эти наборы не удаляются и не ограничиваются по количеству. Как следствие: - неограниченно растёт потребление оперативной памяти процессом vLLM; - увеличивается размер ответа эндпоинта /metrics, что само по себе может исчерпать ресурсы как самого сервиса, так и системы мониторинга, собирающей метрики. Поскольку запросы не требуют аутентификации, атака легко автоматизируется и может выполняться с одного узла. Уязвимости присвоен рейтинг CVSS 5.9 (MEDIUM) — это отражает отсутствие требований к привилегиям и влияние на доступность, но не затрагивает конфиденциальность и целостность данных.Что делать
Основная и достаточная рекомендация — обновить vLLM до версии 0.30.0 или более поздней: именно в 0.30.0 проблема устранена. Обновление следует провести в первую очередь на инсталляциях, чей эндпоинт /metrics доступен из недоверенных сетей или где vLLM выставлен в интернет. Если немедленное обновление невозможно, применяйте компенсирующие меры: - ограничьте сетевой доступ к сервису и к эндпоинту /metrics средствами firewall или reverse-proxy, разрешив только доверенные источники (в первую очередь системы мониторинга); - включите аутентификацию и авторизацию на уровне фронтенда или прокси, чтобы отсекать неаутентифицированные запросы до попадания в vLLM; - по возможности фильтруйте нестандартные HTTP-методы на периметре, допуская только ожидаемые (GET, POST и т. п.); - настройте мониторинг потребления памяти процессом vLLM и размера ответа /metrics, а также алерты на аномальный рост числа временных рядов, чтобы быстрее обнаруживать эксплуатацию; - рассмотрите ограничение частоты запросов (rate limiting) для недоверенных клиентов. Важно понимать, что перечисленные митигации лишь снижают поверхность атаки: они не устраняют первопричину — неограниченное создание меток, — поэтому обновление до 0.30.0 остаётся приоритетным действием. Итог: CVE-2026-105759 — показательный пример уязвимости типа «неконтролируемая кардинальность меток», когда безобидная на первый взгляд телеметрия становится вектором отказа в обслуживании. Атака не требует учётных данных и не оставляет следов в данных, но способна исчерпать память процесса и нарушить работу системы мониторинга. Единственное надёжное решение — переход на vLLM 0.30.0; до этого ограничьте доступ к сервису и эндпоинту /metrics и усильте наблюдение за потреблением ресурсов.Источник: CVE Project (cvelistV5)