vLLM CVE-2026-94624

Exploitation requires the vLLM deployment to enable the P2P secondary tier specifically - OffloadingConnector configured with TieringOffloadingSpec and a p2p secondary tier - which is a non-default configuration. The endpoint must accept client-supplied kv_transfer_params (remote host/port) from API requests, and the attacker needs network reachability to that API. Limiting factors: the vulnerable feature is off by default, and the fix PR explicitly recommends deploying behind a reverse proxy that strips or validates kv_transfer_params, or lowering VLLM_P2P_MAX_PEERS (e.g. 16-32) for public-facing deployments - both of which neutralize the attack. Impact is availability-only (crash of EngineCore stopping all inference); no confidentiality or integrity effect. Because vLLM's OpenAI-compatible server commonly runs without built-in authentication, an exposed instance with P2P enabled is effectively unauthenticated to reach.

This is a genuine availability-focused priority within its narrow deployment gate, but not a mass-exploitation emergency. The vendor CVSS 4.0 base of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N with VA:H and zero confidentiality/integrity impact) correctly frames it as a pure denial-of-service: a network-reachable attacker with API access can crash the EngineCore and halt ALL inference, but no data is read or altered. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or automated exploitation - the signals point to a credible but not-yet-weaponized issue. The most important nuance the raw score obscures is that PR:N assumes an exposed, unauthenticated vLLM API AND that the optional P2P secondary tier is enabled; the fix PR's own documentation states this feature is non-default and recommends stripping kv_transfer_params at a reverse proxy, confirming the flaw is gated on a specific configuration. So the 8.7 is accurate for affected deployments but overstates fleet-wide risk: most vLLM installs do not run OffloadingConnector with a p2p tier and are unaffected. Treat as high priority only where P2P KV-offload is configured on a network-exposed endpoint.

An attacker with network access to a vLLM OpenAI-compatible API endpoint that has OffloadingConnector + TieringOffloadingSpec with a p2p secondary tier enabled sends a stream of inference requests, each carrying kv_transfer_params pointing to a unique, non-listening remote host/port. Each unreachable peer session pins a ZeroMQ socket that is never reclaimed, and once the context quota is exhausted an uncaught ZMQError crashes EngineCore, stopping all inference for every user. No public exploit code was identified at time of analysis, but the attack requires only crafted API parameters and low complexity.