vLLM and trust-remote-code: revision pinning, an API key and code review did not stop one request

If you run vLLM on your own server and serve a multimodal model with --trust-remote-code, you probably rely on three protections. You reviewed the processor code before enabling the flag. You pinned the model revision so the code would not change without your knowledge. You set --api-key so only people you authorized could send requests. A new security advisory from the vLLM project describes a situation where, in a particular configuration with --trust-remote-code, one request to /tokenize can choose which Python code runs on the server. That route is not protected by the API key.

Our argument is that each of these protections is enforced inside the application, by field or route, and relied on an assumption that did not hold. The practical conclusion is to update and, alongside that update, set host-level limits on who can reach the inference server and which destinations it can connect to. Neither decision depends on how vLLM interprets a request.

What was published

On 6 October 2026, security advisory GHSA-h3rc-6mm3-gc2m was published. According to the advisory, a multimodal request can set code_revision within the mm_processor_kwargs field. When the model's processor on Hugging Face is configured as dynamic code (auto_map) and the operator has enabled --trust-remote-code, this value is passed to Transformers' AutoProcessor.from_pretrained. It determines which repository revision the processor code is imported from. Importing a Python module means executing arbitrary code in vLLM's API/renderer process.

Key points from the advisory:

• Versions: From 0.7.3 up to, but not including, 0.31.0. The fix is included in 0.31.0 and was merged in pull request 58830. The advisory notes that the vulnerability was confirmed on a specific commit with Transformers 5.15.0 and 5.16.1, and that the affected version range was not verified through bisecting.
• Conditions: A dynamic processor through auto_map; trust_remote_code enabled; the server can download the revision selected in the request, or that revision is already cached; the attacker can create or control a revision in the repository of the model being served—according to the advisory, a community pull request ref on Hugging Face is one example, where the repository allows it; and a multimodal request reaches the processor code path. With the default configuration, trust_remote_code=False, the server is not affected.
• Authentication: According to the advisory, vLLM's authentication component protects only routes beginning with /v1, /v2, /inference and /cohere. The field is also accepted in a chat tokenize request, so /tokenize remains open even when --api-key is set, unless an external proxy protects it.
• Severity: The reporter proposed a score of 9.8, but the published rating is High, with a CVSS score of 8.1 and high attack complexity. There is no CVE identifier. The classifications are CWE-94 and CWE-829.
• Demonstration: According to the advisory, the demonstration ran without a network connection, a GPU or model weights, and without modifying a real repository. The advisory does not describe exploitation in the wild.

The LinuxSecurity coverage summary describes the update as including critical fixes. However, the rating published in the advisory itself is High.

Revision pinning pins data, not code

An operator who pins revision assumes that this pins everything the model brings with it. According to the advisory, vLLM did pin revision and trust_remote_code, but passed through the remaining request settings without protecting code_revision. Transformers uses this value to select the code, then removes it before loading the processor data. The result, as described in the advisory: the code comes from the attacker-controlled revision, while the configuration and data stay on the revision the operator pinned. If you reviewed the code before enabling the flag, you reviewed one revision. With this vulnerability, a different revision ran.

So --trust-remote-code is not just a technical setting enabled to make a model work. Enabling it is a decision to run code from an external source. The crucial question is who chooses that code. In the vulnerable version, the request made that choice.

An API key protects prefixes, not the server

It is easy to assume that setting --api-key blocks anyone without a key from accessing the server. According to the advisory, protection is defined by route prefixes, and /tokenize is not among them. The vLLM security guide also lists it as an unprotected route. For a vLLM server accessible over the network, asking whether you set a key is not enough. You need to check which routes are accessible without a key and what each one processes.

That makes checking the exposure of the entire service more important than checking the configuration of a single route. If only services that need vLLM can reach its port, the impact of a route left outside the authentication mechanism is greatly reduced.

The ability to download is part of the attack

One condition in the advisory is that the server can download the revision selected in the request, or that the revision is already cached. A server with its model prepared in advance does not necessarily need to contact the repository at runtime. You can block access to any destination it does not need. Remember: if you leave access to Hugging Face itself open, the attacker-controlled revision is in the same repository. Updating to 0.31.0 therefore remains the fix.

The repository condition is also worth checking. According to the advisory, a community pull request ref is an example of a revision an attacker can control, in a repository that allows it. In that sense, a public repository open to contributions is a code source you do not fully control.

The common thread

In all three cases, protection was enforced where the application interprets input: one unprotected field, one excluded route. These protections depend on the developer having considered every field and every route. By contrast, two host-level questions remain the same even when a new field is discovered: who can reach the inference server's port, and which destinations its process can connect to. According to the advisory, the code runs in the API/renderer process and affects confidentiality, integrity and availability.

What to do on your server

1. Update to 0.31.0. Check the version in the process that actually receives requests, not just the tag of the image you downloaded. A running container does not update itself.
2. Check whether you need --trust-remote-code. If the model does not require it, turn it off. If it does, check whether its processor is configured as dynamic code through auto_map.
3. Check the repository of the model being served. Does it allow community pull requests? Who can create revisions in it?
4. Restrict network access to the inference server. Do not expose vLLM directly to the internet. Allow access only to services that need it. If a proxy sits in front of it, make sure the proxy also requires authentication for /tokenize. Test this with a separate request to that route.
5. Map the inference server's outbound traffic. Check which destinations it connects to at runtime, and restrict access to the destinations it actually needs.
6. Check what else is running. It is easy to miss a model server set up for testing and left running on an old version with the flag enabled.

How nuDefend helps

Know what is running. The nudefend workloads command shows the AI tools running on the server, including model servers, whether they run directly on the host or inside a container. Each tool is shown alongside the information used to identify it, such as a systemd unit, an image name or a command-line pattern. This can also help you find a model server that was set up for testing and forgotten.

Know who can reach it. The nudefend expose command shows every service listening on the server and who can reach it, from the server's own perspective. The view also includes services published from containers. If a service that was internal-only becomes accessible from outside, nuDefend detects the change and alerts you. If the inference server is exposed unintentionally, you can block its port from the dashboard or the command line. Before the block is applied, a preview shows exactly what will be blocked. Every block is logged and can be undone with a click. See the exposure page for details.

Control where it connects. nuDefend records which destinations each AI tool on the server connects to, the traffic volume for each destination and when the destination was first detected. When the destination is identified, its name and type of activity are shown, such as a source for software and model downloads. You can use this information to restrict a selected tool to destinations you have approved. Every attempt to connect to another destination is blocked before the traffic leaves the server, while the rest of the server continues to operate normally. nuDefend also restricts which addresses the tool can resolve, and every blocked lookup is shown alongside the tool's name. See the outbound traffic page for details.

A baseline layer. Traffic to and from known malicious IP addresses and domains is blocked by the kernel firewall. Blocking uses signed threat lists that refresh every 30 minutes. The dashboard shows a count of blocked outbound traffic. A value above zero may be an early warning that something on the server tried to contact a malicious source.

The bottom line

The vLLM vulnerability shows that three reasonable protections—revision pinning, an API key and code review—were all enforced inside the application and bypassed through one field and one route. Update to 0.31.0 and turn off --trust-remote-code if you do not need it. Alongside the update, set host-level limits on who can reach the inference server and which destinations it can connect to. Those decisions remain in force when the next field is discovered.