AI Threat AlertCVE-2026-93436: vLLM: memory leak in PD disaggregation causes DoS
HIGHvLLM through 0.29.0 fails to clean up decode-side metadata when a request is rejected in prefill/decode disaggregated deployments, so an unauthenticated remote attacker can send requests with max_tokens=0 and steadily exhaust decode-worker memory until the worker restarts. The flaw is trivial to trigger (network, low complexity, no privileges, CVSS 7.5, availability impact only), but real-world exploitation signals are weak: EPSS is 0.00755 (about the 46th percentile), it is not in CISA KEV, there is no public exploit or Nuclei template, and CISA SSVC says TRACK. Exposure is limited to teams running the experimental disaggregated serving mode (NIXL KV-transfer connector), which is mostly large-scale inference platforms, not typical single-node vLLM installs. Upgrade to a release containing the fix from vllm-project/vllm PR 55677 (any version after 0.29.0), and until then block or validate max_tokens=0 at the gateway and alert on decode-worker memory growth.
What is the risk?
Medium-High. Exploitability is high (remote, unauthenticated, low complexity, single request type), but impact is limited to availability, with no confidentiality or integrity effect. Low EPSS, no KEV listing, no public exploit and an SSVC decision of TRACK suggest opportunistic exploitation is unlikely in the near term. Risk rises for internet-exposed or multi-tenant inference endpoints that use prefill/decode disaggregation, where repeated worker restarts can degrade or interrupt service. The CVSS is the vendor-agnostic base score; exposure depends heavily on whether the disaggregated NIXL connector is enabled.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vLLM to a release that includes the fix from PR 55677 (later than 0.29.0) and confirm against the vendor advisory. 2) If patching is delayed, reject or rewrite requests with max_tokens=0 at the API gateway, reverse proxy or router in front of vLLM. 3) Require authentication and rate limiting on inference endpoints so anonymous clients cannot reach decode paths. 4) Monitor decode-worker resident memory and GPU memory trends, and alert on sustained growth uncorrelated with traffic. 5) Configure automatic worker restarts with health checks and memory limits (container/cgroup limits) to bound blast radius. 6) Inventory deployments to find which ones use disaggregated prefill/decode with NIXL.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-93436?
vLLM through 0.29.0 fails to clean up decode-side metadata when a request is rejected in prefill/decode disaggregated deployments, so an unauthenticated remote attacker can send requests with max_tokens=0 and steadily exhaust decode-worker memory until the worker restarts. The flaw is trivial to trigger (network, low complexity, no privileges, CVSS 7.5, availability impact only), but real-world exploitation signals are weak: EPSS is 0.00755 (about the 46th percentile), it is not in CISA KEV, there is no public exploit or Nuclei template, and CISA SSVC says TRACK. Exposure is limited to teams running the experimental disaggregated serving mode (NIXL KV-transfer connector), which is mostly large-scale inference platforms, not typical single-node vLLM installs. Upgrade to a release containing the fix from vllm-project/vllm PR 55677 (any version after 0.29.0), and until then block or validate max_tokens=0 at the gateway and alert on decode-worker memory growth.
Is CVE-2026-93436 actively exploited?
No confirmed active exploitation of CVE-2026-93436 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-93436?
1) Upgrade vLLM to a release that includes the fix from PR 55677 (later than 0.29.0) and confirm against the vendor advisory. 2) If patching is delayed, reject or rewrite requests with max_tokens=0 at the API gateway, reverse proxy or router in front of vLLM. 3) Require authentication and rate limiting on inference endpoints so anonymous clients cannot reach decode paths. 4) Monitor decode-worker resident memory and GPU memory trends, and alert on sustained growth uncorrelated with traffic. 5) Configure automatic worker restarts with health checks and memory limits (container/cgroup limits) to bound blast radius. 6) Inventory deployments to find which ones use disaggregated prefill/decode with NIXL.
What systems are affected by CVE-2026-93436?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference clusters, prefill/decode disaggregated serving, OpenAI-compatible API gateways.
What is the CVSS score for CVE-2026-93436?
CVE-2026-93436 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.76%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034.001Resource-Intensive QueriesAML.T0040AI Model Inference API AccessCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM through 0.29.0 fails to properly clean up decode-side metadata for rejected inference requests in prefill/decode disaggregated deployments. Remote attackers can submit requests with max_tokens=0 to exhaust decode-worker memory without bound until the worker restarts.
Exploitation Scenario
An attacker finds an exposed OpenAI-compatible vLLM endpoint fronting a disaggregated prefill/decode cluster. They script a loop of cheap completion requests with max_tokens=0, which the system rejects but leaves decode-side metadata allocated. After thousands of requests, decode-worker memory is exhausted and the worker crashes or is killed by the OOM killer. The attacker repeats the attack after each restart, keeping the inference service degraded or offline at almost no cost.
Weaknesses (CWE)
CWE-401Missing Release of Memory after Effective LifetimePrimaryCWE-401Missing Release of Memory after Effective LifetimeCWE-401 — Missing Release of Memory after Effective Lifetime: The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
- [Implementation] Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone. For example, glibc in Linux provides protection against free of invalid pointers. When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391]. To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.
- [Architecture and Design] Use an abstraction library to abstract away risky APIs. Not a complete solution.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm