# vLLM Mooncake ZeroMQ Pickle Deserialization Exposure

- **Severity:** High
- **Signature ID:** `9d4c7e12-6b8a-4f31-b2d7-5e0a91c8f463`
- **CVEs:** CVE-2025-32444
- **OWASP:** LLM03 (Supply Chain)

## Summary

Some versions of vLLM's Mooncake KV-transfer integration open a network socket that accepts and unpickles data from anyone who can reach it. Because Python's pickle deserialization can execute arbitrary code, any host that can connect to that port can run commands as the inference server.

## How the attack works

An operator starts a vLLM server with the Mooncake KV connector enabled, or launches one of the disaggregated-prefill proxy scripts, or runs a bare pyzmq receiver, or starts the Mooncake transfer-engine/master service. In each case the process binds a ZeroMQ socket to all network interfaces and calls recv_pyobj(), which internally runs pickle.loads() on whatever bytes arrive. An attacker who can reach that port sends a crafted pickle payload and gets code execution with the privileges of the serving process. This detection only sees the process being launched — it cannot see the malicious payload itself, since that never passes through the engine that generates the signal.

## Why it matters

An attacker with network access to the exposed port can run arbitrary code on the machine hosting the inference server, potentially leading to full compromise of that host, theft of model data or credentials, and a foothold for further lateral movement.

## What you can do

- Upgrade vLLM to 0.8.5 or later, where this issue is fixed.
- If you must run the Mooncake KV-transfer feature on an older version, isolate it on a private network segment with no route from untrusted hosts, and restrict the ZeroMQ port with firewall rules.
- Never bind these ZeroMQ receivers to 0.0.0.0 or another wildcard address; bind to a specific internal interface instead.
- Audit existing hosts for disaggregated-prefill proxy scripts, Mooncake transfer-engine/master processes, or vLLM launches with kv_connector=Mooncake, and confirm the installed vLLM version and network exposure for each.

## Known benign look-alikes

- Intentional disaggregated-prefill deployment on a patched vLLM (>= 0.8.5) where the Mooncake KV connector is used on a network-isolated RDMA/TCP fabric. The rule cannot read the installed vLLM version from the command line, so this configuration is reported every time the server is (re)started - triage once, then tune per host.
- Performance benchmarking of the Mooncake transfer engine (transfer_engine_bench, mooncake_master) bound to 0.0.0.0 on a lab machine.
- CI jobs that exercise the Mooncake integration - suppressed when launched through pytest/unittest/tox/nox, but a bare `python disagg_prefill_proxy_xpyd.py` inside a CI step will still report.
- An engineer pasting a tutorial command line from the vLLM disaggregated-prefill docs into a shell for a local single-node experiment.
- Internal red-team reproduction of CVE-2025-32444.
- Read-only inspection of these command lines (grep/cat/git/editor) - suppressed by filter_readonly_inspect.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-32444
- https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/
- https://attack.mitre.org/techniques/T1190/
- https://docs.python.org/3/library/pickle.html

---
Source: https://www.netzilo.com/threats/vllm-mooncake-pickle-rce