# vLLM ZeroMQ Pickle Deserialization RCE - Payload Spawn Under Inference Server

- **Severity:** High
- **Signature ID:** `3f7a2c1d-9b64-4e5a-8c2f-1d6b0a94e7c3`
- **CVEs:** CVE-2025-32444
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise)

## Summary

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.

## 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.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-32444
- https://docs.vllm.ai/en/latest/features/disagg_prefill.html
- https://atlas.mitre.org/techniques/AML.T0010
- https://owasp.org/www-project-top-10-for-large-language-model-applications/

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