CVE-2025-47277: Vllm Information Disclosure Vulnerability

CVE-2025-47277 Overview

CVE-2025-47277 is a critical insecure deserialization vulnerability affecting vLLM, an inference and serving engine for large language models (LLMs). The vulnerability exists in versions 0.6.5 through 0.8.4 and specifically impacts environments using the PyNcclPipe KV cache transfer integration with the V0 engine. No other configurations are affected.

The issue stems from how vLLM utilizes PyTorch's TCPStore interface for CPU-side control message passing. While the intention was that this interface should only be exposed to a private network using the IP address specified by the --kv-ip CLI parameter, the default PyTorch behavior causes the TCPStore interface to listen on ALL network interfaces, regardless of the specified IP address. This exposes the deserialization endpoint to potentially untrusted networks, creating a critical attack surface for remote exploitation.

Critical Impact

Remote attackers can exploit the exposed TCPStore interface to send malicious serialized objects, potentially leading to arbitrary code execution on vulnerable vLLM instances. This poses significant risk to AI/ML infrastructure deployments using distributed inference.

Affected Products

• vLLM versions 0.6.5 through 0.8.4
• Environments using PyNcclPipe KV cache transfer integration with V0 engine
• Deployments where TCPStore interface is exposed to untrusted networks

Discovery Timeline

• 2025-05-20 - CVE-2025-47277 published to NVD
• 2025-08-13 - Last updated in NVD database

Technical Details for CVE-2025-47277

Vulnerability Analysis

This vulnerability falls under CWE-502 (Deserialization of Untrusted Data). vLLM supports the use of the PyNcclPipe class to establish a peer-to-peer communication domain for data transmission between distributed nodes. The GPU-side KV-Cache transmission is implemented through the PyNcclCommunicator class, while CPU-side control message passing is handled via the send_obj and recv_obj methods.

The core issue lies in the misunderstanding between intended configuration and actual behavior. When administrators specify a private interface using the --kv-ip CLI parameter, they expect the TCPStore socket to bind exclusively to that interface. However, PyTorch's default behavior ignores this specification for binding purposes, using the provided IP address only as a client-side address. This results in the TCPStore interface binding to 0.0.0.0 (all interfaces), exposing the deserialization endpoint to any network the host is connected to.

Root Cause

The root cause is a behavioral mismatch between vLLM's intended security model and PyTorch's TCPStore implementation. The TCPStore class, by design, binds its listening socket to all available network interfaces regardless of the IP address parameter provided during initialization. vLLM's architecture assumed this parameter would restrict the listening interface, creating an implicit trust boundary that did not actually exist.

The send_obj and recv_obj methods use Python's pickle serialization for object transmission. When exposed to untrusted networks, attackers can craft malicious pickle payloads that execute arbitrary code during deserialization.

Attack Vector

An attacker with network access to the exposed TCPStore interface can:

1. Identify vLLM instances running with PyNcclPipe configuration
2. Connect to the exposed TCPStore socket (which listens on all interfaces)
3. Send malicious serialized Python objects via the recv_obj pathway
4. Achieve remote code execution when the malicious payload is deserialized

The network-based attack vector requires no authentication or user interaction, enabling unauthenticated remote attackers to fully compromise affected systems.

# Security patch from vllm/distributed/utils.py
# Source: https://github.com/vllm-project/vllm/commit/0d6e187e88874c39cda7409cf673f9e6546893e7

 import dataclasses
 import datetime
 import pickle
+import socket
 import time
 from collections import deque
 from typing import Any, Deque, Dict, Optional, Sequence, Tuple

The patch introduces the socket module import, which is used to implement a workaround that forces the TCPStore instance to bind its socket specifically to the configured private interface rather than all interfaces.

Detection Methods for CVE-2025-47277

Indicators of Compromise

• Unexpected network connections to vLLM distributed inference nodes from external IP addresses
• Anomalous pickle deserialization activity or unusual Python object instantiation patterns
• Network traffic to TCPStore ports from non-whitelisted IP ranges
• Evidence of code execution following network connections to distributed inference endpoints

Detection Strategies

• Monitor network traffic for connections to vLLM inference nodes originating from outside expected private network ranges
• Implement network intrusion detection rules to identify pickle-based serialization traffic on unexpected interfaces
• Audit vLLM configurations to identify deployments using PyNcclPipe with V0 engine that may be exposed
• Review firewall logs for connection attempts to distributed inference communication ports from untrusted sources

Monitoring Recommendations

• Deploy network segmentation monitoring to ensure TCPStore interfaces are only accessible from authorized internal networks
• Enable logging for all connections to vLLM distributed inference endpoints
• Implement anomaly detection for unusual process spawning or code execution following network activity on ML infrastructure
• Monitor for unexpected Python subprocess creation or shell command execution on vLLM nodes

How to Mitigate CVE-2025-47277

Immediate Actions Required

• Upgrade to vLLM version 0.8.5 or later which includes the security fix
• Audit all vLLM deployments to identify instances using PyNcclPipe KV cache transfer with V0 engine
• Implement network-level access controls to restrict access to distributed inference communication ports
• Review network configurations to ensure vLLM nodes are isolated on trusted private networks

Patch Information

The vulnerability has been addressed in vLLM version 0.8.5. The fix implements a workaround to force the TCPStore instance to bind its socket to the specified private interface as configured via the --kv-ip parameter, rather than binding to all interfaces.

For detailed information about the security patch, refer to the GitHub Security Advisory GHSA-hjq4-87xh-g4fv and the related pull request.

Workarounds

• If upgrading is not immediately possible, implement strict firewall rules to ensure TCPStore ports are only accessible from authorized nodes within the private network
• Deploy vLLM nodes on isolated network segments with no exposure to untrusted networks
• Consult the vLLM Deployment Security Guide for best practices on securing distributed inference deployments
• Consider temporarily disabling PyNcclPipe KV cache transfer if the distributed functionality is not critical

# Configuration example - Firewall rules to restrict TCPStore access
# Allow TCPStore communication only from trusted private network
iptables -A INPUT -p tcp --dport <tcpstore_port> -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport <tcpstore_port> -s 172.16.0.0/12 -j ACCEPT
iptables -A INPUT -p tcp --dport <tcpstore_port> -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport <tcpstore_port> -j DROP