CVE-2026-105755: в vLLM кэш эмбеддингов уязвим к подмене через X-Request-Id
В vLLM до версии 0.30.0 механика flash late-interaction scoring на эндпоинтах /score и /rerank формирует ключ запроса воркера на основе заголовка X-Request-Id, который контролируется вызывающей стороной. Параллельный запрос с тем же идентификатором способен перезаписать кэшированный эмбеддинг жертвы, из-за чего её документы оцениваются по чужому запросу. Уязвимость имеет уровень CVSS 4.2 (MEDIUM).
Подробности
Уязвимы версии vllm-project vllm до 0.30.0 включительно (то есть все выпуски, предшествующие 0.30.0). Затронуты эндпоинты /score и /rerank, использующие режим flash late-interaction scoring. Механизм проблемы связан с формированием значения query_key для каждого воркера: оно выводится из HTTP-заголовка X-Request-Id, который полностью контролируется клиентом. Если параллельный запрос повторно использует идентификатор, уже применяемый другим (целевым) запросом, возникает коллизия в общем кэше. В результате кэшированный эмбеддинг запроса жертвы может быть перезаписан данными атакующего, и документы жертвы начинают оцениваться относительно чужого запроса. Это нарушает целостность вычислений между запросами: результаты /score и /rerank для пострадавшей стороны оказываются некорректными и не отражают её собственный ввод. Дополнительный эффект связан с общими счётчиками использования (shared use counters): при определённом стечении обстоятельств возможна ошибка промаха кэша late-interaction (cache-miss), что приводит к индуцированным сбоям обработки запросов. Таким образом, последствия варьируются от незаметного искажения результатов ранжирования и оценки до явных ошибок при обслуживании. Стоит отметить, что эксплуатация не требует привилегированного доступа — достаточно возможности отправлять запросы к затронутым эндпоинтам и управлять значением X-Request-Id. Это делает проблему актуальной для многопользовательских развёртываний, где несколько клиентов или сервисов обращаются к одному экземпляру vLLM.Что делать
Основная и наиболее надёжная рекомендация — обновить vLLM до версии 0.30.0 или более поздней: именно в 0.30.0 проблема устранена. После обновления логика кэширования больше не позволяет одному запросу влиять на кэш другого через подконтрольный идентификатор. Если немедленное обновление невозможно, следует рассмотреть временные митигации: — ограничить доступ к эндпоинтам /score и /rerank доверенными клиентами и сегментировать сеть; — контролировать и нормализовать заголовок X-Request-Id на уровне обратного прокси, не допуская повторного использования идентификаторов между разными клиентами; — по возможности снизить уровень параллелизма или изолировать экземпляры vLLM по арендаторам, чтобы разделить общие кэши; — внимательно отслеживать аномалии в ответах /score и /rerank и ошибки промаха кэша как возможные индикаторы эксплуатации. Важно понимать, что перечисленные меры носят компенсирующий характер и не заменяют установку исправленной версии. Итог: CVE-2026-105755 — умеренная по оценке, но практически значимая уязвимость нарушения целостности между запросами в vLLM. Она позволяет подменить кэшированный эмбеддинг запроса и исказить результаты оценки и ранжирования, а также спровоцировать ошибки кэша. Единственное полноценное решение — обновление до vLLM 0.30.0; до его применения стоит ограничить доступ к затронутым эндпоинтам и контролировать X-Request-Id.Источник: CVE Project (cvelistV5)
