CVE-2026-94624: vLLM unbounded P2P KV sessions crash

Q: Is CVE-2026-94624 actively exploited?

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

Q: How to fix CVE-2026-94624?

1) Inventory vLLM instances (versions up to and including 0.29.0) and check whether OffloadingConnector, TieringOffloadingSpec and a P2P secondary tier are enabled; if not, you are not exposed. 2) Upgrade to a release containing the fix from vllm-project/vllm PR #51504 once available, or apply that patch. 3) Until patched, disable P2P KV offloading or the P2P secondary tier. 4) Do not let untrusted clients set kv_transfer_params: strip or reject the field at an API gateway or reverse proxy, and restrict inference endpoints to authenticated, trusted networks. 5) Detection: alert on EngineCore crashes, uncaught zmq.error.ZMQError in vLLM logs, rising ZeroMQ socket or file-descriptor counts, and unusual outbound connection attempts to unexpected hosts and ports from inference nodes. 6) Configure process supervision with restart backoff and health checks to limit outage duration, and apply egress filtering so inference nodes can only reach approved peers.

Q: What systems are affected by CVE-2026-94624?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, disaggregated KV-cache serving, multi-tenant inference gateways.

Q: What is the CVSS score for CVE-2026-94624?

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

CISO Take

vLLM through 0.29.0 has an unauthenticated denial-of-service flaw in its P2P KV offloading path: an attacker who can reach the service supplies arbitrary remote host and port values in kv_transfer_params, creating unreachable peer sessions that pile up ZeroMQ sockets until the context quota is exhausted. The resulting uncaught ZMQError crashes EngineCore and halts all inference for every tenant on that instance. Risk is real but narrow. The flaw is network-reachable, needs no privileges and has low complexity (CVSS 7.5), yet it only affects deployments that explicitly enable OffloadingConnector with TieringOffloadingSpec and a peer-to-peer secondary tier. Exploitation signals are weak: EPSS is 0.63% (around the 52nd percentile), it is not in CISA KEV, there is no public exploit or Nuclei template, and CISA SSVC says TRACK. Identify any vLLM deployments using P2P KV offloading, apply the fix referenced in vllm PR #51504 or upgrade past 0.29.0 once released, and make sure the inference API is not exposed to untrusted callers or that kv_transfer_params cannot be set by them.

Sources:NVDEPSSATLASVulnCheckGitHub

What is the risk?

Medium-High for exposed deployments using P2P KV offloading, low for default configurations. Exploitability is high in principle (network, low complexity, no privileges, no user interaction), but the vulnerable path requires a non-default, relatively new feature combination. Impact is availability only (A:H, no confidentiality or integrity effect). Likelihood of exploitation is currently low: EPSS 0.00627, not in KEV, no public PoC, SSVC TRACK. Exposure rises sharply if the inference endpoint is internet-facing or if untrusted tenants or applications can pass kv_transfer_params.

How does the attack unfold?

Initial Access

Attacker reaches the vLLM inference endpoint over the network with no authentication required.

AML.T0049

Exploitation

Attacker submits requests with kv_transfer_params pointing to unreachable remote host and port values, creating peer sessions that retain ZeroMQ sockets.

AML.T0040

Resource Exhaustion

Accumulated sessions exhaust the ZeroMQ context quota, raising an uncaught ZMQError.

AML.T0029

Impact

EngineCore crashes and all inference stops until restart, and the attack can be repeated.

AML.T0029

Initial Access

Attacker reaches the vLLM inference endpoint over the network with no authentication required.

AML.T0049

Exploitation

Attacker submits requests with kv_transfer_params pointing to unreachable remote host and port values, creating peer sessions that retain ZeroMQ sockets.

AML.T0040

Resource Exhaustion

Accumulated sessions exhaust the ZeroMQ context quota, raising an uncaught ZMQError.

AML.T0029

Impact

EngineCore crashes and all inference stops until restart, and the attack can be repeated.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	< 0.32.0	`0.32.0`
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.4%

chance of exploitation in 30 days

Higher than 38% 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) Inventory vLLM instances (versions up to and including 0.29.0) and check whether OffloadingConnector, TieringOffloadingSpec and a P2P secondary tier are enabled; if not, you are not exposed. 2) Upgrade to a release containing the fix from vllm-project/vllm PR #51504 once available, or apply that patch. 3) Until patched, disable P2P KV offloading or the P2P secondary tier. 4) Do not let untrusted clients set kv_transfer_params: strip or reject the field at an API gateway or reverse proxy, and restrict inference endpoints to authenticated, trusted networks. 5) Detection: alert on EngineCore crashes, uncaught zmq.error.ZMQError in vLLM logs, rising ZeroMQ socket or file-descriptor counts, and unusual outbound connection attempts to unexpected hosts and ports from inference nodes. 6) Configure process supervision with restart backoff and health checks to limit outage duration, and apply egress filtering so inference nodes can only reach approved peers.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoSInferenceFrameworkAML.T0029- Denial of AI Service AML.T0040- AI Model Inference API Access AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Procedures to respond to and recover from unknown risks

OWASP LLM Top 10

LLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-94624?

vLLM through 0.29.0 has an unauthenticated denial-of-service flaw in its P2P KV offloading path: an attacker who can reach the service supplies arbitrary remote host and port values in kv_transfer_params, creating unreachable peer sessions that pile up ZeroMQ sockets until the context quota is exhausted. The resulting uncaught ZMQError crashes EngineCore and halts all inference for every tenant on that instance. Risk is real but narrow. The flaw is network-reachable, needs no privileges and has low complexity (CVSS 7.5), yet it only affects deployments that explicitly enable OffloadingConnector with TieringOffloadingSpec and a peer-to-peer secondary tier. Exploitation signals are weak: EPSS is 0.63% (around the 52nd percentile), it is not in CISA KEV, there is no public exploit or Nuclei template, and CISA SSVC says TRACK. Identify any vLLM deployments using P2P KV offloading, apply the fix referenced in vllm PR #51504 or upgrade past 0.29.0 once released, and make sure the inference API is not exposed to untrusted callers or that kv_transfer_params cannot be set by them.

Is CVE-2026-94624 actively exploited?

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

How to fix CVE-2026-94624?

1) Inventory vLLM instances (versions up to and including 0.29.0) and check whether OffloadingConnector, TieringOffloadingSpec and a P2P secondary tier are enabled; if not, you are not exposed. 2) Upgrade to a release containing the fix from vllm-project/vllm PR #51504 once available, or apply that patch. 3) Until patched, disable P2P KV offloading or the P2P secondary tier. 4) Do not let untrusted clients set kv_transfer_params: strip or reject the field at an API gateway or reverse proxy, and restrict inference endpoints to authenticated, trusted networks. 5) Detection: alert on EngineCore crashes, uncaught zmq.error.ZMQError in vLLM logs, rising ZeroMQ socket or file-descriptor counts, and unusual outbound connection attempts to unexpected hosts and ports from inference nodes. 6) Configure process supervision with restart backoff and health checks to limit outage duration, and apply egress filtering so inference nodes can only reach approved peers.

What systems are affected by CVE-2026-94624?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, disaggregated KV-cache serving, multi-tenant inference gateways.

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

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

What is the AI security impact?

Affected AI Architectures

model servingLLM inferencedisaggregated KV-cache servingmulti-tenant inference gateways

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0040AI Model Inference API Access

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 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 contains a denial of service vulnerability in P2P KV offloading when OffloadingConnector is configured with TieringOffloadingSpec and a peer-to-peer secondary tier. Attackers can supply arbitrary remote host and port values in kv_transfer_params to create unreachable peer sessions that retain ZeroMQ sockets until the context quota is exhausted, causing an uncaught ZMQError that crashes EngineCore and stops all inference.

Exploitation Scenario

An attacker finds an internet-facing or internally reachable vLLM OpenAI-compatible endpoint running a P2P KV offloading configuration. They send a stream of completion requests whose kv_transfer_params point to arbitrary unreachable remote host and port values. Each request creates a peer session that retains a ZeroMQ socket and is never cleaned up. After enough requests the ZeroMQ context quota is exhausted, an uncaught ZMQError is raised, EngineCore crashes and all inference stops. The attacker repeats the requests after each restart to keep the service down, disrupting customer-facing AI features or internal agents.

Weaknesses (CWE)

CWE-770Allocation of Resources Without Limits or ThrottlingPrimary CWE-770Allocation of Resources Without Limits or ThrottlingPrimary CWE-770Allocation of Resources Without Limits or Throttling

CWE-770 — Allocation of Resources Without Limits or Throttling: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

[Requirements] Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
[Architecture and Design] Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Source: MITRE CWE corpus.