vLLM 0.31.0 closes five 6 October advisories, led by a code_revision flaw that can run attacker code with --trust-remote-code. No CVE ids yet; scores disagree.
vLLM published five security advisories on 6 October 2026, all fixed in release 0.31.0. The most serious, GHSA-h3rc-6mm3-gc2m, lets a request choose which revision of a model's Hugging Face processor code gets imported. On servers started with --trust-remote-code, that can mean remote code execution in the API process. None of the five advisories has a CVE id, so track them by GHSA id. For the rest of the release, including the breaking flag changes, see our vLLM 0.31.0 upgrade notes.
The code_revision flaw (GHSA-h3rc-6mm3-gc2m)
A multimodal request can set mm_processor_kwargs.code_revision. Request values are merged over the startup configuration, the request value wins, and the processor-kwarg filter keeps code_revision. The loader pins revision and trust_remote_code but not code_revision, so Transformers imports dynamic auto_map.AutoProcessor code from whichever revision the caller names. The operator's pinned model revision stays in place, but the executed Python can come from another revision of the same repository. The code runs in the API process.
The advisory rates it High, CVSS 8.1 (AV:N/AC:H/PR:N), CWE-94 and CWE-829. Its own text argues that the affected configuration deserves AC:L and 9.8, so the score on the page and the score in the text disagree. Affected: vllm >=0.7.3 and <0.31.0; the range was not bisected. Fix: 0.31.0 (PR #58830).
The five vLLM advisories published 6 October 2026, by CVSS score as listed on each advisory page. None has a CVE id.
Exposure needs all of the following:
--trust-remote-codeis on (default is off, and off is not affected).- The served model's processor uses dynamic
auto_mapcode. - The attacker can make a revision of that repository exist, for example a Hub pull-request ref where those are allowed, and the server can fetch it or already has it cached.
- A multimodal request reaches the processor.
The entry point is /tokenize, plus chat completions. vLLM's authentication middleware covers only the /v1, /v2, /inference and /cohere prefixes, so /tokenize is open even when --api-key is set, unless a proxy in front guards it.
EngineCore crash (GHSA-p92p-rxj5-7p2x)
Moderate, CVSS 6.5 (AV:N/AC:L/PR:L/A:H), CWE-345, affects versions below 0.31.0, fixed by PR #57833. The reporter reproduced it on the vllm/vllm-openai:v0.29.0 image with default settings. The advisory title says unauthenticated, but the vector carries PR:L, so the title and the score do not match either.
A client-supplied uuid on image_url, video_url or input_audio parts becomes the cache key (mm_hash) verbatim. Two LRU caches, P0 in the API process and P1 in EngineCore, evict independently. P0 is written before prompt-length validation, so rejected requests still alter it. A P1 hit returns cached data without checking modality, shape or token count, and the resulting placeholder mismatch in _merge_multimodal_embeddings is fatal to EngineCore. The engine stays down until someone restarts it. The endpoints named are /v1/chat/completions and /v1/responses. No user-side workaround is listed, and the project's "Multimodal Media UUID Security" guidance does not address it.
The other advisories from 6 October
| Advisory | Issue | Severity | Affected |
|---|---|---|---|
| GHSA-4xqp-c3mv-qff7 | min_tokens of 2147483648 with null max_tokens on /inference/v1/generate kills the EngineCore input thread while /health stays 200 | Moderate, 6.5 | <0.31.0 (PR #57731) |
| GHSA-823j-m4cj-hmjf | MOSS-Audio models: unbounded processor cache fed by /tokenize mm_processor_kwargs, memory exhaustion | High, 7.5 | >0.24.0, <0.31.0 |
| GHSA-6cxc-2vcg-w5qc | Stale allowed_token_ids mask in recycled batch slots constrains another client's request | Low, 3.7 | <0.31.0 per metadata, text says <=0.30.0 (PR #43931) |
The hang is the operationally nasty one: health checks pass while the engine's input thread is dead. The route is mounted by default in v0.29.0 and is unauthenticated unless --api-key is set. For the MOSS-Audio bug, --api-key does not cover /tokenize; the advisory suggests an authenticating or rate-limiting reverse proxy as a stopgap.
What to check
- Upgrade to vllm 0.31.0 or later. For the crash advisory (p92p) no user-side workaround is listed.
- Find servers launched with
--trust-remote-codeand check whether the model's processor usesauto_map.AutoProcessor. If you do not need remote code, turn it off. - Do not expose
/tokenizeor/inference/*directly. Put authentication or rate limiting at a proxy, since--api-keydoes not guard/tokenize. Setting--api-keydoes guard/inference/v1/generatefor the 4xqp hang. - Check that no external user can create revisions of your model repositories, and review which revisions are in your Hugging Face cache.
- Alert on generation latency or queue depth, not just
/health, given the 4xqp hang. - Five earlier advisories, published on 3, 12 and 23 September, appear on the same advisory list; check their affected ranges against your version.