vLLM CVE-2026-114053: code_revision Request Field Gives Remote Code Execution

vLLM versions from 0.7.3 up to 0.31.0 let a client choose which revision of a model's processor code the server imports. CVE-2026-114053, published as GHSA-h3rc-6mm3-gc2m, is rated high (CVSS 3.1 8.1). When trust_remote_code is enabled, the import runs attacker-controlled Python inside the vLLM API process. Upgrade to 0.31.0 or later, and put authentication in front of /tokenize. If you serve models with trust_remote_code=False, the default, you are not affected.

For coding-agent users the relevance is the serving side: teams that self-host an open-weight model for their agents often run vLLM behind a gateway, and the host usually holds model weights, provider keys and network access to internal services. This is a separate event from the multimodal denial-of-service bugs in our earlier vLLM post, though the same release fixes both. The tool's page in the Beam CVE database is vLLM.

Quick answers

What the advisory says

According to the GitHub advisory, published October 6, 2026, a client can set code_revision inside mm_processor_kwargs on a multimodal request. vLLM passes that value to the Transformers function AutoProcessor.from_pretrained, which imports the processor's Python code from the requested revision of the model repository. The operator's pinned model revision is unchanged, but the module that executes is not. The weaknesses are CWE-94 (code injection) and CWE-829 (inclusion of functionality from an untrusted control sphere). The advisory lists an EPSS value of 0.462% and notes that the start of the affected range has not been bisected, so older releases than 0.7.3 may also be affected. We found no report of exploitation in the wild.

The root cause is a trust-boundary mistake. Arguments that decide how the server is built from a repository (which revision of code to load) were accepted in the same dictionary as arguments that tune a single request. Operators pin a model revision precisely so that the code they reviewed is the code that runs. A request-time field that overrides the code revision defeats that pin.

The attack chain, step by step

1. The server runs with trust_remote_code enabled and serves a model whose processor ships Python code through auto_map. Many multimodal models do.
2. The attacker controls a revision of the model repository. The advisory gives a community pull-request ref as an example: on Hugging Face, anyone can open a pull request against a public model, and that creates a ref holding the proposed files.
3. They place malicious processor code in that revision.
4. They send a multimodal request with mm_processor_kwargs.code_revision set to their ref. The advisory notes the /tokenize endpoint accepts mm_processor_kwargs and sits outside the authentication middleware, so no API key is needed unless an external proxy protects it.
5. vLLM calls AutoProcessor.from_pretrained with the attacker's revision. Transformers imports the module from that ref.
6. Importing the module runs the attacker's Python in the API process, with the server's permissions.

Each condition narrows the exposure, which explains the high attack-complexity rating. But the conditions are ones many self-hosted setups meet: trust_remote_code is often enabled to get a new multimodal model running, and public repositories accept pull-request refs by design.

Who is affected

Operators of vLLM from 0.7.3 up to below 0.31.0 who enabled trust_remote_code. If you serve only models that need no remote code, or you leave the flag at its default of false, the advisory says you are not affected. The reachable-from-the-network piece matters too: an inference server bound to localhost behind an authenticating proxy that also covers /tokenize is much harder to reach than one exposed directly. The Symantec report on exposed AI endpoints shows how quickly attackers find unprotected inference hosts.

Understanding trust_remote_code and auto_map

Hugging Face model repositories can ship Python alongside weights. A model's config can declare an auto_map that points the Transformers Auto* classes at custom modules in the repository, for example a processor that prepares images or audio for a multimodal model. Because that is arbitrary code, Transformers refuses to run it unless the caller opts in with trust_remote_code. The flag is the operator's statement that "I reviewed this repository and I accept what it runs."

That statement is only meaningful for a specific commit. The operator reviews the files at one revision, then serves that revision. CVE-2026-114053 breaks the link between the two: the operator's opt-in stays in force, but the request decides which revision's code gets imported. A reviewed, pinned model and an attacker's pull-request ref look identical to the loader, and the opt-in covers both.

Why the pull-request ref matters

The advisory's example attacker controls "a revision in the served model repository, such as a community pull-request ref". On the Hugging Face hub, a pull request against a model repository creates a ref that anyone with an account can populate with files, without the owner merging anything. That puts attacker-written processor code at a name the server can be told to fetch. The owner of the model never has to be compromised. Only the server needs to accept a revision name from a stranger.

This is also why the defensive fix is at the API boundary and not in the model hub. Hubs will keep allowing pull-request refs, so the serving layer has to ignore loader controls in request bodies, whatever the hub holds.

Why a pinned revision is not a pin if requests can override it

Supply-chain guidance for models repeats one rule: pin to an exact commit and review the code you pin. That protects against a repository owner changing files later. It does not help if the server lets the caller name a different commit at request time. This bug is a reminder to check what a "pin" actually guards: the default the operator sets, or the final value used after every layer of overrides.

The advisory's remediation direction is general and worth copying into your own services: separate processor-construction arguments from request-time arguments, ideally with an allowlist; reject code_revision and similar loader controls in request payloads; use only the operator's model_config.code_revision; add a regression test proving requests cannot change the loaded module revision; and require authentication on /tokenize.

The same shape appeared elsewhere this month. In Langflow and LiteLLM, configuration-level controls reachable by lower-trust callers became code execution. And the backdoored Qwen open-weight model case shows why model repositories deserve the same suspicion as packages.

What this means if you run AI coding agents

1. Check the version. Run pip show vllm on the host or inside the container and read Version. For images, check the digest.
2. Upgrade to 0.31.0 or later. Rebuild images rather than patching in place. That release also contains the fixes from our earlier post on the multimodal DoS bugs.
3. Check whether trust_remote_code is on. Look at your launch command or config for --trust-remote-code. If a model does not need it, turn it off. If it does, review the repository code at the exact commit you serve and pin that commit.
4. Put authentication in front of every route, including /tokenize. The advisory says the endpoint bypasses vLLM's auth middleware. A reverse proxy that requires a token for all paths closes that gap on older versions too. This is our suggestion rather than a documented workaround.
5. Do not expose the server directly to the internet. Bind to a private interface and let the gateway handle access.
6. Look for signs of abuse. The advisory lists no indicators, so these are our suggestions: requests to /tokenize or other endpoints containing code_revision, new outbound fetches to the model hub for refs you do not use, and unexpected child processes from the API server.
7. Reduce what the server can reach. Run it as an unprivileged user without cloud credentials in its environment. If you find evidence of exploitation, treat anything the process could read as exposed and follow our rotation runbook.

What developers should take from it

Two habits generalize beyond vLLM. First, treat every field a client can send as hostile until an allowlist says otherwise, especially fields that name a code location, a file path or a URL. Second, keep a written list of which services run with remote code enabled, so a disclosure like this one takes minutes to triage instead of an afternoon. If your agents call a self-hosted model through a gateway, include that gateway and the inference server in the same inventory, along with the versions in use.

What Beam can and cannot do here

Beam does not apply to this server-side flaw. It runs on a developer machine, watching what Claude Code, Codex and similar agents do, flagging risky actions such as credential exposure and destructive commands, and scanning skills and MCP configs with its heuristics and a version-pin check. It does not inspect or monitor a vLLM server.

The nearest overlap is conceptual. Beam's MCP config scan flags unpinned dependency references on the client side, which is the same "what exactly am I running" question this bug raises for model code. That scan is heuristic and on-device, and it does not touch model repositories or inference servers. See what Beam watches and how it works.

Frequently asked questions

Which vLLM versions are affected by CVE-2026-114053?

The advisory lists vLLM from 0.7.3 up to but not including 0.31.0, which contains the fix. The default trust_remote_code=False setting is not affected.

What conditions are needed to exploit it?

The served model's processor must use dynamic auto_map code, the operator must have enabled trust_remote_code, the attacker must control a revision of the model repository (such as a community pull-request ref), and a multimodal request must reach the processor path.

Why does the /tokenize endpoint matter?

It accepts mm_processor_kwargs and is not covered by vLLM authentication middleware, so it stays reachable without an API key unless a proxy in front protects it.

How severe is it?

The GitHub advisory gives CVSS 3.1 8.1 (high) with high attack complexity. The CVE record also carries a CVSS 4.0 score of 9.2, which is why it appears as critical in the Beam CVE database.

Is there a workaround besides upgrading?

Upgrade to 0.31.0 or later. If you cannot yet, leave trust_remote_code off where possible and require authentication in front of /tokenize and the other API routes. These are our suggestions, not the advisory's workarounds.

Can Beam detect or block this?

No. Beam runs on a developer machine and does not inspect inference servers. It can scan skill and MCP configs and flag risky agent actions locally.

Related reading

• vLLM multimodal DoS advisories and the 0.31.0 update
• vLLM 0.32.0: eight more advisories, including SHM pickle RCE
• LiteLLM salt key reuse privilege escalation
• Backdoored Qwen open-weight model
• MCP security in practice
• Sources: GHSA-h3rc-6mm3-gc2m, the NVD record and the vLLM repository

Versions and advisory details are accurate as of October 27, 2026. Check the linked advisory and vLLM's release notes for changes.