CVE-2025-30202: Vllm Vllm ZeroMQ 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 up to (but not including) 0.8.5 expose an XPUB ZeroMQ socket bound to all network interfaces in multi-node deployments. Any client with network access to the primary vLLM host can connect to this socket, receive internal broadcast traffic intended for secondary nodes, and disrupt service availability. The flaw is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The vLLM project addressed the issue in version 0.8.5.

Critical Impact

Unauthenticated attackers on the network can connect to the exposed XPUB socket and slow or block legitimate publishers, causing denial of service across multi-node vLLM clusters.

Affected Products

• vLLM versions 0.5.2 through 0.8.4 (multi-node deployments)
• vLLM tensor-parallel configurations across multiple hosts
• Any vLLM host exposing the XPUB ZeroMQ port without firewall restrictions

Discovery Timeline

• 2025-04-30 - CVE-2025-30202 published to NVD
• 2025-05-14 - Last updated in NVD database

Technical Details for CVE-2025-30202

Vulnerability Analysis

vLLM uses ZeroMQ for inter-node communication in distributed deployments. The primary host opens an XPUB (extended publish) socket to broadcast state to secondary nodes participating in tensor parallelism. The socket is created during multi-node initialization regardless of whether cross-host tensor parallelism is actively used.

Because the socket binds to the wildcard address, every network-reachable client can subscribe to the publisher. Subscribers receive internal vLLM state messages broadcast to legitimate worker nodes. The exposure is reachable across the network without authentication or user interaction.

The primary risk is availability. ZeroMQ XPUB sockets apply backpressure when subscribers fail to read queued messages. An attacker who opens many subscriptions and never consumes data can stall or block the publisher, degrading throughput for the entire inference cluster.

Root Cause

The root cause is an insecure default bind address in vllm/distributed/device_communicators/shm_broadcast.py. The remote ZeroMQ socket was configured with tcp://*:{port}, binding to every interface on the host. No allowlist, authentication, or resource throttling was applied to incoming subscribers, satisfying the conditions for [CWE-770].

Attack Vector

An attacker with network access to the primary vLLM host connects to the exposed XPUB port using any ZeroMQ subscriber client. After subscribing, the attacker either passively collects broadcast internal state or intentionally refuses to read incoming messages. Repeating this from multiple connections amplifies backpressure on the publisher and degrades or halts cross-node communication.

                 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:

Source: vLLM commit a0304dc. The patch replaces the wildcard bind with a specific connect_ip, restricting the socket to the intended interface.

Detection Methods for CVE-2025-30202

Indicators of Compromise

• Unexpected ZeroMQ TCP connections to the primary vLLM host from systems outside the trusted worker pool
• Sustained high connection counts on the XPUB subscriber port without corresponding read activity
• vLLM publisher threads stalled or reporting backpressure warnings in application logs
• Degraded inference throughput correlated with new external TCP sessions to the vLLM host

Detection Strategies

• Inventory all vLLM deployments and verify versions against 0.8.5 using pip show vllm or container image manifests
• Audit listening sockets on vLLM primary hosts with ss -tlnp and confirm ZeroMQ ports are not bound to 0.0.0.0
• Monitor netflow or VPC flow logs for connections to vLLM ZeroMQ ports originating outside the cluster subnet

Monitoring Recommendations

• Alert on new TCP listeners bound to wildcard interfaces on hosts running vllm processes
• Track connection count and read/write ratios on ZeroMQ XPUB ports to detect non-consuming subscribers
• Forward vLLM application logs to a central data lake and alert on publisher backpressure or worker disconnect events

How to Mitigate CVE-2025-30202

Immediate Actions Required

• Upgrade all vLLM installations to version 0.8.5 or later
• Restrict access to vLLM ZeroMQ ports using host firewalls or network security groups, allowing only worker node IPs
• Place multi-node vLLM clusters on isolated, non-routable management networks
• Audit existing deployments for unexpected external connections to ZeroMQ ports

Patch Information

The fix is included in vLLM 0.8.5 via commit a0304dc504c85f421d38ef47c64f83046a13641c. The patch binds the remote ZeroMQ socket to the specific connect_ip rather than the wildcard address. Details are available in the GitHub Security Advisory GHSA-9f8f-2vmf-885j and Pull Request #6183.

Workarounds

• Block external access to vLLM ZeroMQ ports with iptables, nftables, or cloud security group rules
• Bind vLLM hosts to a dedicated private interface used exclusively for inter-node traffic
• Disable multi-node deployment where tensor parallelism across hosts is not required

# Restrict ZeroMQ port to the worker subnet only (example for iptables)
iptables -A INPUT -p tcp --dport <zmq_port> -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport <zmq_port> -j DROP