vLLM, an inference and serving engine for large language models (LLMs), has an issue in versions 0.6.5 through 0.8.4 that ONLY impacts environments using the `PyNcclPipe` KV cache transfer integration with the V0 engine. No other configurations are affected. 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 on the CPU side. 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 vLLM documentation covers how this must be limited to a secured network. The default and intentional behavior from PyTorch is that the `TCPStore` interface listens on ALL interfaces, regardless of what IP address is provided. The IP address given was only used as a client-side address to use. vLLM was fixed to use a workaround to force the `TCPStore` instance to bind its socket to a specified private interface. As of version 0.8.5, vLLM limits the `TCPStore` socket to the private interface as configured.
The CPU control message mechanism in the `PyNcclPipe` class uses `send_obj` and `recv_obj` methods, which rely on the `TCPStore` interface from the PyTorch library. According to PyTorch's default behavior, `TCPStore` binds the socket to all available network interfaces, ignoring the IP address passed via the `--kv-ip` parameter. As a result, the interface intended only for private network access was publicly exposed. The vulnerability is classified as CWE-502 (deserialization of untrusted data), meaning an attacker can submit a crafted object that will be deserialized on the server side.
An unauthenticated remote attacker can submit a malicious serialized payload to the `TCPStore` interface, which may result in arbitrary code execution (RCE) on the inference node, and consequently full system compromise, breach of data confidentiality and integrity, and service unavailability.
vLLM should be updated to version 0.8.5 or later, in which `TCPStore` has been fixed to bind the socket exclusively to the specified private network interface. Until the update is applied, inference nodes must be absolutely isolated at the network level (firewall, segmentation) to ensure the `TCPStore` interface is not accessible from untrusted networks, in accordance with vLLM documentation recommendations for secure deployment.
vLLM versions 0.6.5 to 0.8.4 — exclusively in configurations using `PyNcclPipe` integration for KV cache transfer with the V0 engine. Other configurations are not vulnerable.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HVllm
APPVllm0.6.5 – 0.8.5 (bez)
Related vulnerabilities
Pominięcie uwierzytelnienia w vLLM — bypass klucza API OpenAI
vLLM: wyciek adresu sterty umożliwiający RCE przez endpoint multimodalny
RCE w vLLM poprzez deserializację pickle na niezabezpieczonych gniazdach ZeroMQ
RCE przez niebezpieczną deserializację w vllm MessageQueue.dequeue()
RCE przez niebezpieczną deserializację w vLLM z Mooncake (ZMQ/TCP)