vLLM EUVD-2026-58064

Exploitation requires enable_prompt_embeds to be explicitly set in the vLLM server configuration - this is a non-default setting that must be deliberately enabled by operators to support multimodal prompt embedding workflows. The attacker must be able to submit concurrent POST /v1/chat/completions requests carrying arbitrary prompt_embeds payloads; depending on deployment, the API may be exposed without authentication (CVSS PR:N assessment) or behind access controls not modeled in the base score. The race requires near-simultaneous concurrent requests to achieve the Thread A-enter / Thread B-enter / Thread A-exit / Thread B-load interleaving, captured by the CVSS 4.0 AT:P (Attack Requirements: Present). Exploitation is bounded to the prompt embedding deserialization path and does not provide code execution, credential access, or lateral movement - only availability impact to the vLLM inference process.

The CVSS 4.0 base vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N, score 6.3) characterizes this as a network-reachable, low-complexity, unauthenticated attack with an attack requirement (AT:P) reflecting the non-default enable_prompt_embeds configuration. Impact is limited to vulnerable-system availability at Low severity, meaning partial disruption rather than complete service crash. The metadata tag 'Information Disclosure' conflicts with the CVSS VC:N rating; no confidentiality impact is substantiated by the description or diff, and this discrepancy should be verified with the vendor. No EPSS data was provided. With no KEV listing, no public exploit, a non-default feature flag requirement, and Low availability impact, this is a low-to-medium real-world priority - meaningful for ML inference infrastructure teams using prompt embeddings but not broadly urgent. The race condition adds timing dependency that the CVSS 4.0 AT:P appropriately captures; however, AC:L suggests the race window is not considered a significant engineering barrier given modern concurrent HTTP frameworks.

An attacker with access to a vLLM API endpoint (with enable_prompt_embeds enabled) sends two near-simultaneous POST /v1/chat/completions requests: one containing a legitimate prompt embedding and one containing a crafted malicious sparse tensor with out-of-bounds indices constructed with check_invariants=False. The asyncio.gather-dispatched thread pool creates the race window where Thread A enables the invariant check, Thread B's malicious tensor is deserialized during that window, Thread A completes and restores the disabled state, and Thread B's tensor then reaches to_dense() without the guard active - causing a runtime error or availability disruption. No public proof-of-concept exploit exists, though the security advisory and PR #48583 test code fully document the attack interleaving.