CVE-2025-29783: vLLM Allows Remote Code Execution via Mooncake Integration
Summary When vLLM is configured to use Mooncake, unsafe deserialization exposed directly over ZMQ/TCP will allow attackers to execute remote code on distributed hosts. Details 1. Pickle deserialization vulnerabilities are well documented. 2.
Published Mar 19, 2025 · Updated Jul 2, 2025
Affected packages
vllm
- Ecosystem
- PyPI
- Affected
- >= 0.6.5, < 0.8.0
- Fixed in
- 0.8.0
- Check
pip show vllm
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
Summary
When vLLM is configured to use Mooncake, unsafe deserialization exposed directly over ZMQ/TCP will allow attackers to execute remote code on distributed hosts.
Details
- Pickle deserialization vulnerabilities are well documented.
- The mooncake pipe is exposed over the network (by design to enable disaggregated prefilling across distributed environments) using ZMQ over TCP, greatly increasing exploitability. ~~Further, the mooncake integration opens these sockets listening on all interfaces on the host, meaning it can not be configured to only use a private, trusted network.~~
Only sender_socket and receiver_ack are allowed to be accessed publicly, while the data actually decompressed by pickle.loads() comes from recv_bytes. Its interface is defined as self.receiver_socket.connect(f\"tcp://{d_host}:{d_rank_offset + 1}\"), where d_host is decode_host, a locally defined address 192.168.0.139,from mooncake.json (https://github.com/kvcache-ai/Mooncake/blob/main/doc/en/vllm-integration-v0.2.md?plain=1#L36).
- The root problem is `recv_tensor()` calls `_recv_impl` which passes the raw network bytes to
pickle.loads(). Additionally, it does not appear that there are any controls (network, authentication, etc) to prevent arbitrary users from sending this payload to the affected service.
Impact
This is a remote code execution vulnerability impacting any deployments using Mooncake to distribute KV across distributed hosts.
Remediation
This issue is resolved by https://github.com/vllm-project/vllm/pull/14228
Credited to JosephTLucas, russellb, kexinoh.
References
- https://github.com/vllm-project/vllm/security/advisories/GHSA-x3m8-f7g5-qhm7
- https://github.com/vllm-project/vllm/pull/14228
- https://github.com/vllm-project/vllm/commit/288ca110f68d23909728627d3100e5a8db820aa2
- https://nvd.nist.gov/vuln/detail/CVE-2025-29783
- https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2025-63.yaml
- https://github.com/advisories/GHSA-x3m8-f7g5-qhm7
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
More vLLM vulnerabilities
All vLLM entriesCVE-2026-105752
vLLM: Harmony tool continuations drop `cache_salt` — restoring a cross-tenant prefix-cache membership oracle
low3.1Oct 6, 2026CVE-2026-105753
vLLM: Mirrored multimodal IPC caches desync after a rejected request — a later request reusing the same media hash trips a receiver assertion in the engine core
medium6.5Oct 6, 2026CVE-2026-105754
vLLM: Scale-out disaggregated multimodal transport trusts caller-supplied features
medium6.5Oct 5, 2026CVE-2026-105755
vLLM: Flash late-interaction scoring caches query embeddings under a caller-controlled request id — cross-request integrity break and induced errors on `/score` and `/rerank`
medium4.2Oct 5, 2026CVE-2026-105756
vLLM: Loose `cache_salt` validation lets a single request kill EngineCore on LMCache-MP deployments — uncaught downstream `ValueError` denial of service
medium6.5Oct 5, 2026CVE-2026-105757
vLLM: Structured-output request errors escape the request boundary and terminate the shared EngineCore — engine-fatal denial of service (3 sites)
medium6.5Oct 5, 2026
