CVE-2024-9053 is a critical (CVSS 9.8) remote code execution flaw in vLLM 0.6.0. The AsyncEngineRPCServer passes received messages to cloudpickle.loads() without checking them, so a crafted message can run code. The record names no fixed release, so upgrade after checking the vLLM release notes and keep the RPC port private.
What's affected
The record names vllm-project vllm version 0.6.0. The vulnerable code is in the AsyncEngineRPCServer() entry points: the server loop calls a handler builder that uses cloudpickle.loads() directly on messages it receives.
Pickle is a Python format that can run code when it is loaded. Loading data from an untrusted sender is therefore the same as running code the sender chose. The record says this can lead to remote code execution through malicious pickle data.
The record does not give a fixed version, and the huntr report could not be read automatically. Read the vLLM release notes and security advisories for the first release after 0.6.0 that changes how the RPC server handles messages. Also check whether you expose the RPC server at all. Many deployments only use the HTTP API.
How to check if you're exposed
Check which version of the package your environments have installed.
pip show vllm
pip list | grep -i vllm
Run the commands inside each virtual environment, container image and notebook environment that might use it, because the system Python often differs from the project one. For a lockfile or requirements file, search for vllm and read the pinned version.
Then find how your inference service is started and whether the internal RPC socket is bound to a network interface or only to a local address. Check firewall and security group rules for any port used by the engine RPC.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can read a dependency manifest and flag known vulnerable versions without installing anything.
What to do now
- List vllm installs and container images and note the version.
- Upgrade to a release after 0.6.0 that the project says changes the RPC handling, after reading its notes.
- Make sure the engine RPC endpoint is not reachable from untrusted networks.
- Run inference servers with minimal credentials and network egress.
- Rebuild container images so the old version does not linger in a cached layer.
- Add a dependency scan to CI so pinned model server versions are checked on each build.
Why it matters
Python pickle is a code format as much as a data format. Loading it runs instructions embedded in the data. That is fine for files you made yourself and dangerous for anything that crosses a trust boundary.
The record maps this to deserialization of untrusted data. The standard fix is to replace pickle on network paths with a data only format such as JSON or a schema based format, or to authenticate the peer before reading anything. The fact that the server is an internal component does not make it safe, since inference hosts often hold model weights, API keys and access to GPU clusters.
The weakness class is CWE-502: Deserialization of Untrusted Data, CWE-78: OS Command Injection. The CVSS vector in the record is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which scores 9.8. This CVE is not listed in the CISA Known Exploited Vulnerabilities catalog at the time of writing.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is pickle dangerous?
Loading pickle can run code, so loading it from an untrusted sender lets the sender run code on your server.
Does my HTTP API expose the RPC server?
Not necessarily. Check how your deployment binds the RPC endpoint.
Sources
Last reviewed: 19 October 2026.