Skip to content
Fencer Vulns
high 7.5

CVE-2025-30202 json

Data exposure via ZeroMQ on multi-node vLLM deployment

published 2025-04-29 18 mo ago modified 2026-08-07 3 mo ago also EUVD-2025-12672 , GHSA-9f8f-2vmf-885j , PYSEC-2026-2016

cvss
7.5
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.6%
EPSS 0.6% chance of exploitation in 30 days, percentile 49%
public exploits
0
none known

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.

Patch / fix

  • pypi vllm 0.8.5
  • vllm-project vllm 0.8.5
  • vllm vllm 0.8.5

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2025-30202 updated cvss 7.5

vllm: Data Exposure via ZeroMQ on Multi-Node vLLM Deployment

  • Red Hat Enterprise Linux AI (RHEL AI) rhelai1/ui-rhel9, rhelai1/bootc-amd-rhel9, rhelai1/bootc-intel-rhel9, rhelai1/bootc-nvidia-rhel9, rhelai1/bootc-azure-amd-rhel9, rhelai1/instructlab-amd-rhel9, +6 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
yes
Technical impact
partial
Assessed
18 mo ago

Exploit prediction

0.61% chance of exploitation in the next 30 days, higher than 49% of all scored CVEs (FIRST EPSS, 2026-11-08).

Exploits and checks

  • github.com https://github.com/vllm-project/vllm/security/advisories/GHSA-9f8f-2vmf-885j referenced PoC, tagged "exploit" by a source, unverified

CVSS scores

assigned by version score vector
CNA 3.1 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
GitHub 3.1 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
NVD 3.1 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
OSV 3.1 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Affected packages

ecosystem package affected fixed in
pypi vllm
>=0.5.2, <0.8.5
0.8.5

Affected products

  • vllm-project vllm

Classification

Weakness
  • CWE-770 Allocation of Resources Without Limits or Throttling

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.