CVE-2025-30202: Vllm Vllm DoS Vulnerability

CVE-2025-30202 Overview

CVE-2025-30202 affects vLLM, a high-throughput inference and serving engine for large language models (LLMs). Versions from 0.5.2 through 0.8.4 bind an XPUB ZeroMQ socket to all network interfaces during multi-node deployments. Any network-reachable client can connect to this socket, receive broadcast internal state, and disrupt the publisher by failing to read messages. This results in denial of service against tensor-parallel vLLM clusters and unintended exposure of internal communication data. The issue is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling]. Maintainers patched the vulnerability in version 0.8.5 by binding the socket to a specific interface rather than all interfaces.

Critical Impact

Unauthenticated network attackers can exhaust the ZeroMQ publisher in multi-node vLLM deployments, stalling tensor-parallel inference and degrading availability of LLM serving infrastructure.

Affected Products

• vLLM versions 0.5.2 through 0.8.4
• Multi-node vLLM deployments using tensor parallelism across hosts
• Inference services built on the vllm:vllm Python package

Discovery Timeline

• 2025-04-30 - CVE-2025-30202 published to NVD
• 2025-04-30 - vLLM security advisory GHSA-9f8f-2vmf-885j published
• 2025-05-14 - Last updated in NVD database

Technical Details for CVE-2025-30202

Vulnerability Analysis

vLLM uses ZeroMQ for inter-host coordination in multi-node deployments. The primary host opens an XPUB socket and binds it to publish coordination data to secondary hosts performing tensor parallelism. The vulnerability stems from the socket being bound to tcp://*:{port}, which listens on every interface available to the process. The socket is opened for every multi-node deployment, even when tensor parallelism across hosts is not active.

Attackers with network reachability to the XPUB port can subscribe and receive all data broadcast to legitimate secondary nodes. While the data is internal vLLM state, the broader impact is on availability. ZeroMQ XPUB sockets apply backpressure when subscribers do not consume messages. An attacker can connect many subscribers and refuse to read, slowing or blocking the publisher and disrupting model-serving operations.

Root Cause

The root cause is an insecure default network binding combined with no limit on subscriber connections. Binding to 0.0.0.0 exposes a service intended for internal cluster communication to any reachable host. Lack of throttling on ZeroMQ subscribers allows resource exhaustion through slow or inactive consumers.

Attack Vector

The attack requires only network access to the vLLM primary host's XPUB port. No authentication, no user interaction, and low complexity are required. Successful exploitation degrades or halts inference traffic across the cluster.

# Patch applied in vllm/distributed/device_communicators/shm_broadcast.py
# Source: https://github.com/vllm-project/vllm/commit/a0304dc504c85f421d38ef47c64f83046a13641c
                self.remote_socket.setsockopt(IPV6, 1)
                remote_addr_ipv6 = True
                connect_ip = f"[{connect_ip}]"
-           socket_addr = f"tcp://*:{remote_subscribe_port}"
+           socket_addr = f"tcp://{connect_ip}:{remote_subscribe_port}"
            self.remote_socket.bind(socket_addr)
            remote_subscribe_addr = f"tcp://{connect_ip}:{remote_subscribe_port}"
        else:

The fix replaces the wildcard bind with the specific connect_ip, restricting exposure to the intended interface used for inter-node communication.

Detection Methods for CVE-2025-30202

Indicators of Compromise

• Unexpected TCP connections to the vLLM ZeroMQ XPUB port from hosts outside the inference cluster subnet.
• Multiple long-lived subscriber connections from the same external client to the XPUB port.
• vLLM publisher latency spikes or stalls without corresponding increases in inference workload.
• Listening socket bound to 0.0.0.0 on the vLLM primary host on versions prior to 0.8.5.

Detection Strategies

• Inventory all vLLM deployments and compare installed versions against 0.8.5 to identify exposure.
• Use ss -ltnp or netstat -lntp on inference hosts to confirm whether ZeroMQ sockets bind to all interfaces.
• Monitor flow logs for east-west and north-south connections to ephemeral or known vLLM ZeroMQ ports.
• Alert on connections to the XPUB port that originate from outside the dedicated cluster network range.

Monitoring Recommendations

• Capture process-to-port mappings on inference hosts and forward to a centralized log store for review.
• Track publisher throughput and subscriber connection counts from vLLM telemetry where available.
• Correlate firewall logs with vLLM service performance metrics to identify abusive subscribers.

How to Mitigate CVE-2025-30202

Immediate Actions Required

• Upgrade vLLM to version 0.8.5 or later on all primary and secondary nodes.
• Restrict network access to vLLM ZeroMQ ports using host firewalls or network ACLs limited to cluster peers.
• Place multi-node vLLM deployments on a dedicated private network segment isolated from user and tenant traffic.
• Audit existing deployments for unexpected subscribers on the XPUB socket before applying the patch.

Patch Information

The fix is contained in vLLM commit a0304dc and Pull Request #6183. Full advisory details are available in GHSA-9f8f-2vmf-885j. Upgrade with pip install --upgrade vllm>=0.8.5.

Workarounds

• Block the ZeroMQ XPUB port at the host firewall, allowing only the IP addresses of trusted secondary nodes.
• Deploy vLLM behind a network policy in Kubernetes that restricts ingress to the inference namespace.
• Bind the vLLM service to an internal management interface using OS-level network namespaces or interface restrictions.

# Restrict ZeroMQ XPUB port to cluster peers only using iptables
# Replace <ZMQ_PORT> with the vLLM ZeroMQ port and <PEER_CIDR> with the cluster subnet
iptables -A INPUT -p tcp --dport <ZMQ_PORT> -s <PEER_CIDR> -j ACCEPT
iptables -A INPUT -p tcp --dport <ZMQ_PORT> -j DROP

# Verify the vLLM ZeroMQ socket is no longer bound to all interfaces
ss -ltnp | grep python