Model Serving RCE - vLLM RPC Pickle Deserialization Exploit
vLLM, a popular tool for serving large language models, has an internal RPC channel that deserializes attacker-supplied data using Python's pickle format. Pickle deserialization can be weaponized to run arbitrary code, so an attacker who can reach this RPC interface can potentially execute commands on the server hosting the model.
How the attack works
An attacker crafts a malicious pickle payload containing a code-execution gadget, such as a __reduce__ method that calls os.system, subprocess, or eval. They target vLLM's AsyncEngineRPCServer or related RPC classes, often reachable over zmq, ipc://, or a tcp host:port. When the server deserializes the payload with cloudpickle or pickle, the embedded code executes on the host running vLLM. This can happen as an initial exploitation attempt, a scripted proof-of-concept run, or a repeated post-exploitation step.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3f1d2e-9c84-4a17-b0e5-2f6a8d41c9e3
- Severity
- High
Why it matters
Successful exploitation gives an attacker code execution on the machine serving the model, which can lead to data theft, lateral movement, or full host compromise. This rule only covers the moment a single malicious command line is spawned; it does not track what happens afterward.
What you can do
- →Restrict network access to vLLM's RPC interface (zmq/ipc/tcp) to trusted hosts only; do not expose it to the internet or untrusted internal segments.
- →Upgrade vLLM to a version that removes or secures the unsafe pickle-based RPC deserialization, if available from the project.
- →Run vLLM serving processes with least-privilege accounts and network segmentation so a compromised model server cannot reach sensitive systems.
- →Review command-line and process logs for cloudpickle/pickle loads combined with code-execution calls (os.system, subprocess, eval) near vLLM RPC components, and confirm any hits are authorized testing before dismissing them.
Known benign look-alikes
- vLLM's own unit and integration tests that round-trip cloudpickle-serialized RPC*Request messages through a zmq ipc:// socket (suppressed by filter_test_harness when invoked via pytest/tox/unittest).
- Authorised red-team or patch-validation work reproducing the advisory PoC in a lab; the command line is indistinguishable from the real exploit by design.
- Security tooling (bandit, semgrep, codeql) or a dependency scanner whose argv embeds the vulnerable snippet (suppressed by filter_static_analysis).
- An engineer grepping the vLLM source for cloudpickle.loads or AsyncEngineRPCServer (suppressed by filter_code_search).
- Training material, advisories or incident notes pasted into a shell command (suppressed by filter_docs).
- Rare distributed-serving launchers that base64-pickle a config onto argv; these only reach the rule if they also carry a vLLM RPC identifier or an exec gadget in the same command line.