vLLM EUVD-2026-109441

Exploitation requires: (1) the V1 engine, (2) an active KVConnectorBase_V1 subclass whose get_num_new_matched_tokens() returns num_new > 0 - in-tree examples are LMCacheConnectorV1 (any prefix cache hit), NixlConnector (decode side of disaggregated P/D), SharedStorageConnector, P2pNcclConnector, OffloadingConnector, and MultiConnector - and (3) a client request with sampling_params.prompt_logprobs set, or echo=true plus logprobs over the OpenAI-compatible API, issued against a connector-cached prefix. The attacker must share an EngineCore with the victim (multi-tenant serving). Limiting factors: the KV connector is NOT a default configuration (plain vLLM without --kv-transfer-config / kv_transfer_config is not reachable, and the local prefix cache is explicitly gated off in kv_cache_manager.py when prompt_logprobs is set), the attacker needs a valid API client (PR:L), and prompt_logprobs/logprobs/echo are the only request switches that reach the crash path, so stripping them at a gateway blocks it. lm-eval-harness multiple-choice workloads (MMLU, ARC, HellaSwag, BBH, PIQA) against vLLM+LMCache are the highest-exposure case since they require prompt_logprobs by definition.

This is a credible operational priority for anyone running vLLM multi-tenant inference with a KV connector, but the raw 8.3 should be read with its preconditions in mind. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates a network-reachable, low-complexity attack requiring low privileges (a valid API client sharing the EngineCore), with impact confined to availability - VA:H plus SA:H reflects that a single crash takes down co-tenant traffic, a genuine cross-tenant blast radius rather than self-DoS. No EPSS score and no KEV status were provided, so there is no evidence of active exploitation; exploitation status is: no public exploit identified at time of analysis. However, the GHSA advisory supplies an exact file/function (LogprobsTensors.empty_cpu() in vllm/v1/outputs.py), the triggering request shape, and a one-line diff, so the barrier to weaponization is very low even without published exploit code. The vuln.today decision label is 'this_week', not act_now/emergency, consistent with a serious-but-not-under-active-exploitation DoS. The key limiting factor - exploitation requires a KV connector (LMCache, NIXL, etc.) to be enabled, which is not vLLM's default - keeps this below ubiquitous-risk status; without a connector, the code path is latent and unreachable. Confidentiality and integrity are unaffected, so this is purely an availability/DoS concern.

An attacker holding a valid API client on a shared vLLM V1 engine that has a KV connector (e.g. LMCache) enabled warms or reuses a connector-cached prefix, then sends one request with prompt_logprobs set (or echo=true plus logprobs). The uninitialized int32 tensor positions decode to garbage, tokenizer.decode() raises OverflowError, EngineCore dies, and every in-flight co-tenant request on that engine is dropped. No published working exploit exists, but the advisory documents the exact trigger and a request can be repeated as a kill-loop; with AV:N/AC:L the request is trivial to craft remotely.