Home / Guides / vLLM 0.31.0 advisories

vLLM 0.31.0 security fixes your scanner may not show you

Two high-severity vLLM advisories are fixed in 0.31.0. Neither has a CVE ID, so CVE-based scanners may miss them.

Published · Source: github.com/vllm-project

Last reviewed: · 5 min read

vLLM published two high-severity advisories on 6 October 2026, GHSA-h3rc-6mm3-gc2m and GHSA-gx7p-2j49-hfq4. Both concern per-request mm_processor_kwargs and are fixed in vLLM 0.31.0, released 5 October 2026. Both advisories list no CVE ID, so tools that match on CVEs or public advisory feeds may not flag an older vLLM.

Key takeaways

  • Both advisories list vLLM from 0.7.3 as affected and 0.31.0 as patched.
  • One allows code execution when trust_remote_code is on.
  • The other lets one request exhaust memory and stop the server.
  • vLLM 0.31.0 rejects per-request multimodal kwargs by default.
  • Both advisories carry no CVE ID.

What do the two advisories say?

GHSA-h3rc-6mm3-gc2m is rated high. It says a multimodal request can set mm_processor_kwargs.code_revision. When the served model’s processor uses dynamic code and the operator enabled trust_remote_code, that value chooses which revision of the processor code Transformers imports. The advisory calls this arbitrary code execution in the vLLM API process. It states the default trust_remote_code=False configuration is not affected.

GHSA-gx7p-2j49-hfq4 is also rated high (CVSS 3.1 score 7.5). Clients can pass image size, patch count or frame count through mm_processor_kwargs. For processors that upscale inputs, the advisory says one request can force an allocation large enough to end the server with an out-of-memory error.

Why might a scanner miss them?

Both advisories show No known CVE. On 16 October 2026 neither GHSA ID was returned by the GitHub Advisory Database API or by the OSV database, which many dependency scanners use. A scan of vLLM 0.30 could therefore come back clean while both issues are present. Check the vLLM repository’s security advisories page directly.

What changed in 0.31.0?

The 0.31.0 release notes say per-request mm_processor_kwargs and media_io_kwargs now return an error unless the server starts with --trust-request-mm-kwargs. Server-level --mm-processor-kwargs and offline use are unchanged. The fix is pull request #58830.

The code execution advisory also notes that /tokenize stays unauthenticated even with --api-key set, unless a proxy protects it. vLLM’s own security guide lists it as an unprotected endpoint.

Who should act first?

Start with servers that take multimodal requests from clients you do not fully trust. Shared internal platforms count, as well as public APIs. The denial-of-service advisory notes that the vLLM API key is optional, so a server without an authenticating proxy in front is reachable by anyone on its network. An inference server is an API like any other, and API penetration testing checks whether /tokenize and the other endpoints are reachable without a key.

Sorami’s view

This section is opinion. It is our reading of the vLLM advisories, not a statement from the vLLM project.

A clean dependency scan is not the same as a patched model server. For inference engines that move this fast, read the project’s advisory page as part of each upgrade, not only the scanner output.

Leave the new flag off. --trust-request-mm-kwargs restores per-request overrides, so it belongs only where every client is trusted. If you need trust_remote_code, pin and review the model repository and keep the server off networks where untrusted clients can reach it.

What to do now

  1. List every vLLM server and its running version.
  2. Upgrade anything from 0.7.3 up to 0.31.0.
  3. Check whether any server runs with trust_remote_code enabled.
  4. Leave --trust-request-mm-kwargs off unless every client is trusted.
  5. Put an authenticating proxy in front of /tokenize and other routes.
  6. Add the vLLM security advisories page to your upgrade checks.

If you serve models to other teams or customers and want the inference API tested, see our AI application penetration testing, or contact us to discuss scope.

Sources

Facts on this page were checked against these sources on 16 October 2026. We update the page when the source changes.

Questions before you book

Practical answers.

Which vLLM version fixes GHSA-h3rc-6mm3-gc2m?

vLLM 0.31.0, released 5 October 2026. The advisory lists versions from 0.7.3 up to 0.31.0 as affected.

Do the vLLM 0.31.0 advisories have CVE IDs?

No. Both GHSA-h3rc-6mm3-gc2m and GHSA-gx7p-2j49-hfq4 show No known CVE on the vLLM advisory pages.

Is vLLM affected if trust_remote_code is off?

The code execution advisory says the default trust_remote_code=False configuration is not affected. The denial-of-service advisory does not depend on that setting.

What does --trust-request-mm-kwargs do?

From 0.31.0, vLLM rejects per-request mm_processor_kwargs and media_io_kwargs. Starting the server with --trust-request-mm-kwargs restores them for trusted deployments.

Let’s scope it

Serving models to other teams?

Send the vLLM version, models and how the API is exposed. We will scope a test of the inference layer.

Send an enquiry