CVE-2026-94626: vLLM unvalidated tp_size

CISO Take

vLLM through 0.29.0 does not validate the tp_size value in kv_transfer_params on its OpenAI-compatible completion endpoints, so an unauthenticated remote caller can force unbounded memory allocation and get the decode worker OOM-killed by the kernel. Only prefill/decode disaggregated deployments using the NIXL KV connector are exposed, which narrows the blast radius, but those are typically production-scale clusters where losing a decode worker drops capacity and interrupts in-flight requests. Exploitation is low-complexity (network, no privileges, no user interaction), yet the EPSS score is 0.00627 (around the 52nd percentile), there is no public exploit, no Nuclei template, and it is not in CISA KEV, so this is a patch-in-cycle item, not an emergency. Upgrade to a vLLM release that includes the fix from upstream PR #51137, and until then make sure the completion endpoints are not reachable by untrusted clients and that kv_transfer_params is stripped or validated at the gateway.

Sources:NVDEPSSATLASVulnCheck advisoryGitHub (vllm-project/vllm)

What is the risk?

High severity (CVSS 7.5, availability-only impact). Exploitability is trivial because the flaw is reachable over the network without authentication or user interaction, but it requires a disaggregated prefill/decode deployment using the NIXL connector, which limits exposure. Real-world exploitation likelihood is currently low to moderate: EPSS is 0.00627, no public exploit or scanner template exists, and it is not in CISA KEV. The impact is confined to availability; there is no confidentiality or integrity effect. Risk rises sharply for internet-exposed or multi-tenant inference endpoints without an authenticating gateway. Package-level risk data (dependents, OpenSSF score) was unavailable, so the blast radius across downstream users is unknown.

How does the attack unfold?

Initial Access

Attacker reaches an exposed OpenAI-compatible completion endpoint of a disaggregated vLLM deployment.

AML.T0040

Exploitation

Attacker submits a request with an arbitrary large tp_size in kv_transfer_params that is never validated.

AML.T0049

Resource Exhaustion

The decode worker attempts unbounded memory allocation based on the attacker-supplied value.

Impact

The kernel OOM-kills the decode worker, denying inference service until restart, and repeated requests sustain the outage.

AML.T0029

Initial Access

Attacker reaches an exposed OpenAI-compatible completion endpoint of a disaggregated vLLM deployment.

AML.T0040

Exploitation

Attacker submits a request with an arbitrary large tp_size in kv_transfer_params that is never validated.

AML.T0049

Resource Exhaustion

The decode worker attempts unbounded memory allocation based on the attacker-supplied value.

Impact

The kernel OOM-kills the decode worker, denying inference service until restart, and repeated requests sustain the outage.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
96.0K94 dependentsPushed 5d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 50% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to a release containing the fix from upstream PR #51137 (versions after 0.29.0) and confirm against the project's advisory. 2) Until patched, place an authenticating API gateway or reverse proxy in front of the OpenAI-compatible endpoints and reject or strip the kv_transfer_params field from external requests; restrict it to trusted internal prefill/decode orchestration traffic. 3) Do not expose vLLM endpoints directly to the internet; use network segmentation and allowlists between the router, prefill, and decode tiers. 4) Set container and cgroup memory limits on decode workers so a runaway allocation is contained and does not take down the host, and configure restart backoff. 5) Detection: alert on decode worker OOM-kill events (dmesg or container OOMKilled status), sudden memory spikes, and requests containing kv_transfer_params with abnormally large tp_size values.

How is it classified?

DoSInferenceAPIAML.T0029- Denial of AI Service AML.T0034.001- Resource-Intensive Queries AML.T0040- AI Model Inference API Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Response to unknown risks and mechanisms to supersede or deactivate systems

OWASP LLM Top 10

LLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-94626?

vLLM through 0.29.0 does not validate the tp_size value in kv_transfer_params on its OpenAI-compatible completion endpoints, so an unauthenticated remote caller can force unbounded memory allocation and get the decode worker OOM-killed by the kernel. Only prefill/decode disaggregated deployments using the NIXL KV connector are exposed, which narrows the blast radius, but those are typically production-scale clusters where losing a decode worker drops capacity and interrupts in-flight requests. Exploitation is low-complexity (network, no privileges, no user interaction), yet the EPSS score is 0.00627 (around the 52nd percentile), there is no public exploit, no Nuclei template, and it is not in CISA KEV, so this is a patch-in-cycle item, not an emergency. Upgrade to a vLLM release that includes the fix from upstream PR #51137, and until then make sure the completion endpoints are not reachable by untrusted clients and that kv_transfer_params is stripped or validated at the gateway.

Is CVE-2026-94626 actively exploited?

No confirmed active exploitation of CVE-2026-94626 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-94626?

1) Upgrade vLLM to a release containing the fix from upstream PR #51137 (versions after 0.29.0) and confirm against the project's advisory. 2) Until patched, place an authenticating API gateway or reverse proxy in front of the OpenAI-compatible endpoints and reject or strip the kv_transfer_params field from external requests; restrict it to trusted internal prefill/decode orchestration traffic. 3) Do not expose vLLM endpoints directly to the internet; use network segmentation and allowlists between the router, prefill, and decode tiers. 4) Set container and cgroup memory limits on decode workers so a runaway allocation is contained and does not take down the host, and configure restart backoff. 5) Detection: alert on decode worker OOM-kill events (dmesg or container OOMKilled status), sudden memory spikes, and requests containing kv_transfer_params with abnormally large tp_size values.

What systems are affected by CVE-2026-94626?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference clusters, prefill/decode disaggregated deployments, OpenAI-compatible API gateways.

What is the CVSS score for CVE-2026-94626?

CVE-2026-94626 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.63%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference clustersprefill/decode disaggregated deploymentsOpenAI-compatible API gateways

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0034.001Resource-Intensive Queries

AML.T0040AI Model Inference API Access

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM10

What are the technical details?

Original Advisory

vLLM through 0.29.0 fails to validate the tp_size parameter in kv_transfer_params on OpenAI-compatible completion endpoints, allowing attackers to allocate unbounded memory. Attackers can supply arbitrary tp_size values in prefill/decode disaggregated deployments to exhaust memory and trigger kernel OOM-kill of the decode worker process.

Exploitation Scenario

An attacker finds an exposed or weakly authenticated vLLM completion endpoint fronting a disaggregated prefill/decode cluster. They send a crafted OpenAI-compatible completion request with kv_transfer_params containing an extreme tp_size value. The decode worker trusts the value while building NIXL metadata and attempts to allocate memory proportional to it, so the kernel OOM-killer terminates the process. By repeating the request whenever the worker restarts, the attacker keeps the inference service degraded or offline at almost no cost.

Weaknesses (CWE)

CWE-789Memory Allocation with Excessive Size ValuePrimary CWE-789Memory Allocation with Excessive Size Value

CWE-789 — Memory Allocation with Excessive Size Value: The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

[Implementation, Architecture and Design] Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
[Operation] Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

Source: MITRE CWE corpus.