vLLM MooncakeConnector CVE-2026-94625

Requires the target to run vLLM (through 0.29.0) configured for disaggregated prefill/decode with the MooncakeConnector KV-transfer backend (kv_producer/kv_consumer roles) - this is a non-default, specialized topology, not a standard single-node vLLM serve. Given that configuration, exploitation is remote and unauthenticated (AV:N/PR:N/UI:N): the attacker only needs network access to submit prefill requests that get rejected before engine admission, triggering ownerless placeholders. Limiting factors: the non-default connector requirement is the primary constraint; impact is bounded to availability degradation (delays up to ~480 seconds and sender-pool exhaustion) rather than crash or data compromise, and the silent nature (health checks still succeed) affects detection rather than exploitability.

Signals converge on a genuine but bounded availability issue, not a top-tier priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L, 6.9) confirms remote unauthenticated exploitation with LOW availability impact only - no confidentiality or integrity effect, consistent with CWE-772 (missing release of resource). No EPSS score, no CISA KEV listing, and no standalone proof-of-concept were provided (the referenced PR #51236 is the fix diff plus regression tests, not exploit code), so this is 'no public exploit identified at time of analysis.' The most under-appreciated risk factor is the description's note that health checks keep returning success while valid requests are delayed up to 480 seconds - meaning the degradation is silent and could evade standard liveness monitoring. Balancing against that: exploitation is gated on a non-default deployment topology (disaggregated prefill/decode using MooncakeConnector), which sharply narrows the real exposed population despite vLLM's broad footprint. Net: a real, low-effort DoS worth patching for anyone running the affected connector, but not an emergency for the majority of vLLM operators who do not use Mooncake KV transfer.

An attacker with network reach to a vLLM decode/proxy endpoint repeatedly submits prefill requests crafted to be rejected before engine admission; each one causes the prefiller to create an ownerless transfer placeholder that is never reclaimed. Sustained flooding exhausts the sender task pools so legitimate inference requests stall for up to ~480 seconds, while health checks continue reporting the service as healthy. No public exploit code exists - only the upstream fix PR and its regression tests.