# vLLM GroupCoordinator recv_object Pickle Deserialization RCE

- **Severity:** High
- **Signature ID:** `b7f4c2a1-9e63-4d0f-8a51-3c6d5e2f7b94`
- **MITRE ATLAS:** AML.T0050 (Command and Scripting Interpreter)
- **OWASP:** LLM03 (Supply Chain)

## Summary

vLLM 0.6.0 has a flaw where a worker process trusts and deserializes raw pickle data sent to it over its internal distributed-inference transport. Because pickle can run arbitrary code during deserialization, an attacker who can reach that transport can make the vLLM worker spawn a shell or run commands.

## How the attack works

An attacker sends a crafted pickle payload to the recv_object() function used by vLLM's GroupCoordinator for inter-worker communication. Python's pickle.loads() executes attacker-controlled code as part of deserializing the object, with no validation of what was sent. This shows up on the host as the vLLM or torchrun worker process suddenly spawning a shell, script interpreter, or network tool. The rule confirms this by tracing the exact process lineage back to a real vLLM/distributed-worker process, then checking for a suspicious child process (like `python -c` or `/bin/sh`) within a short time window, plus a second corroborating signal such as outbound network traffic from that child or a matching second payload-shaped exec in the same process tree.

## Why it matters

Successful exploitation gives an attacker arbitrary code execution on the machine hosting the vLLM inference worker, which can lead to data theft, lateral movement, or full host compromise — all from a service that was only meant to serve model inference.

## What you can do

- Do not expose vLLM's distributed-inference transport (used for multi-node/multi-GPU coordination) to untrusted networks; restrict it to a private, trusted network segment.
- Upgrade vLLM past the affected version or apply any available patch that validates or removes unsafe pickle deserialization in GroupCoordinator.
- Review container entrypoints, health checks, and model-fetch scripts around your vLLM deployment so you can distinguish legitimate shell-outs from injected payloads.
- Monitor vLLM/torchrun worker processes for unexpected child processes (shells, interpreters, curl/wget to unfamiliar hosts) shortly after startup or during inference.

## Known benign look-alikes

- Container entrypoint or launcher scripts that wrap the vLLM server and shell out (`bash -c "..."`, `sh -c "exec vllm serve ..."`) — these appear as a payload-shaped child of a lineage that already contains the vllm marker.
- Kubernetes liveness/readiness probes or sidecar health checks implemented as `sh -c "curl -sf localhost:8000/health"` executed inside the vLLM pod.
- Model-fetch helpers spawned by the serving stack (`curl`/`wget`/`huggingface-cli` pulling weights) during first start-up of a distributed worker.
- Benchmark, profiling and CI harnesses that launch vLLM under torchrun and then run `python -c` probes or `nvidia-smi` wrappers in the same process subtree.
- Ray worker bootstrap under tensor parallelism, which re-execs Python and may make HTTP calls to the Ray dashboard/GCS from processes below the worker.

## References

- https://cwe.mitre.org/data/definitions/502.html
- https://github.com/vllm-project/vllm/blob/main/vllm/distributed/parallel_state.py
- https://docs.vllm.ai/en/latest/serving/distributed_serving.html
- https://owasp.org/www-project-top-10-for-large-language-model-applications/

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