Data exposure via ZeroMQ on multi-node vLLM deployment
Key facts
- Attack vector
- Network
- Privileges required
- None
- User interaction
- None
- Attack complexity
- Low
- Impact type
- Denial of service
- Confidentiality · integrity · availability
- None · None · High
- Fix status
- Fixed
Attack profile from CVSS 3.1 · CNA. Fix status from CNA and GitHub. Impact type from CWE-770.
Summary
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Versions starting from 0.5.2 and prior to 0.8.5 are vulnerable to denial of service and data exposure via ZeroMQ on multi-node vLLM deployment. In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes. The primary vLLM host opens an XPUB ZeroMQ socket and binds it to ALL interfaces. While the socket is always opened for a multi-node deployment, it is only used when doing tensor parallelism across multiple hosts. Any client with network access to this host can connect to this XPUB socket unless its port is blocked by a firewall. Once connected, these arbitrary clients will receive all of the same data broadcasted to all of the secondary vLLM hosts. This data is internal vLLM state information that is not useful to an attacker. By potentially connecting to this socket many times and not reading data published to them, an attacker can also cause a denial of service by slowing down or potentially blocking the publisher. This issue has been patched in version 0.8.5.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- Yes
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| vllm-project | vllm | 0.5.2 to before 0.8.5 | 0.8.5 | Patch available | CNA |
| — | vllm (PyPI) | 0.5.2 to before 0.8.5 | 0.8.5 | Patch available | GHSA-9f8f-2vmf-885j |
- vllm Vendorvllm-project Affected 0.5.2 to before 0.8.5 Fixed in 0.8.5 Patch available CNA
- vllm (PyPI) Vendor— Affected 0.5.2 to before 0.8.5 Fixed in 0.8.5 Patch available GHSA-9f8f-2vmf-885j
Remediation
- Fix · CNA vllm (vllm-project) Fixed in 0.8.5
- Fix · GHSA-9f8f-2vmf-885j vllm (PyPI) Fixed in 0.8.5 Advisory →
Vendor assessments
Red Hat
Red Hat rating: Important. Red Hat's page for this CVE →
Not affected: 1 product
- Red Hat Enterprise Linux AI (RHEL AI)
Timeline
- 2026-10-02 Threatist record created from CVE-2025-30202
- 2026-10-03 Alias added: GHSA-9f8f-2vmf-885j
References
Patch 2
Advisory 2
More vllm-project vulnerabilities
- TI-2024-10229 Remote Code Execution in vllm-project/vllm CVSS 3.0CRITICAL 9.8
- TI-2024-08404 Remote Code Execution in vllm-project/vllm CVSS 3.1CRITICAL 9.8
- TI-2026-36017 vLLM: OpenAI auth bypass CVSS 3.1CRITICAL 9.1
- TI-2026-63056 vLLM before 0.28.0 Denial of Service via negative token ID CVSS 4.0HIGH 8.7
- TI-2026-04308 Hardcoded trust_remote_code=True in vllm-project/vllm Bypasses User Security Control CVSS 3.0HIGH 8.8
- TI-2026-39137 vLLM: Remote DoS in vLLM via Invalid Recovered Token Reinjection CVSS 3.1HIGH 7.5
Sources
- CVE-2025-30202 · CVE Program
- CVE-2025-30202 · NVD
- FIRST EPSS
- GHSA-9f8f-2vmf-885j · GitHub Advisory Database · CC BY 4.0
- CVE-2025-30202 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences