vLLM ZeroMQ Pickle Deserialization RCE - Payload Spawn Under Inference Server
A known flaw in vLLM's ZeroMQ-based KV-cache transfer feature (versions 0.6.5–0.8.4) lets anyone who can reach the exposed network socket send a malicious data payload that the server unpacks unsafely, causing it to run arbitrary code. This rule watches for the moment that code execution actually happens, not the network exploit itself.
How the attack works
The vLLM server binds a ZeroMQ socket to all network interfaces without authentication. An attacker who can reach that socket sends a crafted pickle-serialized object. When vLLM deserializes it, embedded logic (via Python's __reduce__ mechanism) calls os.system or subprocess.Popen to run a shell command. The rule detects this by watching for the vLLM server process, or any process descended from it, spawning a new command — the telltale sign that the deserialization exploit succeeded.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f7a2c1d-9b64-4e5a-8c2f-1d6b0a94e7c3
- Severity
- High
- CVEs
- CVE-2025-32444
Why it matters
A successful attack gives an outsider arbitrary code execution inside the model-serving process, with no authentication required — enough to steal data, pivot into the container/host, or hijack the GPU-serving workload.
What you can do
- →Do not expose the vLLM ZeroMQ socket on public or untrusted network interfaces; bind it to localhost or an internal-only network.
- →Upgrade past the affected version range (0.6.5–0.8.4) or apply the vendor's fix for the mooncake/KV-transfer deserialization flaw.
- →Restrict network access to the inference server with firewall rules or network policies so only trusted KV-cache peers can connect.
- →Review any process spawned by the vLLM server or its descendants for unexpected shell commands, especially outside known maintenance or startup automation.
Known benign look-alikes
- Operators or MLOps automation running maintenance one-liners (curl ... | bash, pip install from a script, chmod +x /tmp/setup.sh) inside the same container and under the vLLM entrypoint lineage. These are genuine matches of the payload signature and are reported, not blocked, so a human can confirm the change window.
- Ray / Kubernetes init, readiness or postStart hooks that download and execute a bootstrap script while parented to the vLLM serving process during pod startup.
- Benchmark, profiling or model-download harnesses launched from inside the server process that fetch an artefact into /tmp or /dev/shm and mark it executable.
- Configuration-management agents (cron/systemd/authorized_keys edits) that happen to run as descendants of the serving process on a shared GPU host.
- A payload command line that itself contains the string "vllm" could in principle be mistaken for the server anchor; the rule rejects any lineage entry whose own command line matches a payload signature, so the anchor must be a distinct, non-payload process instance.