AI-Assisted Audit Lands Nine vLLM CVEs as 0.31.0 Locks Down Per-Request Media Options

Nine CVE records for vLLM, the open-source inference and serving engine behind many self-hosted LLM deployments, went public late on October 5, 2026. CVE-2026-105752 through CVE-2026-105760 were published by GitHub as CNA between 22:32 and 23:01 UTC, and NVD listed all nine at 23:17 UTC with the status Received. None is rated Critical or High. The CNA’s CVSS 3.1 scores run from 3.1 (Low) to 6.5 (Medium). What makes the batch worth reading is where the bugs sit. Most of them let a single request crash or slow a shared engine, or weaken the isolation between tenants that operators turn on deliberately. Eight are fixed in vLLM 0.30.0, which reached PyPI on September 22. The ninth, CVE-2026-105753, is fixed in 0.28.0.

Who found them

Six of the nine GitHub advisories credit Patch the Planet, described in the advisories as a Trail of Bits and OpenAI collaboration, and state that the flaws “were discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.” Another, the Qwen video sampler issue, credits Eva Crystal (0xiviel) of XSource Security. The advisories were published in the vLLM repository on September 23 and 28, about a week before the CVE records appeared. Six of them say a proposed fix was submitted as a public pull request.

That makes the batch an example of AI-assisted auditing applied to AI infrastructure. The advisories are detailed: each names the affected code paths and preconditions, and several include suggested patches and regression tests.

One request, one shared engine

vLLM runs inference in a shared EngineCore process, so an unhandled error there affects every concurrent user, not just the request that caused it. Four advisories describe ways to reach that failure:

• CVE-2026-105757 (6.5). Failures in structured-output requests could escape request-scoped validation and hit the engine’s fatal-error path. The advisory lists three separate sites, including a grammar compilation exception and empty values that the Rust frontend accepted but the Python frontend rejected.
• CVE-2026-105756 (6.5). On deployments using the LMCache-MP connector, a cache_salt value that broke that connector’s character or length rules could raise an uncaught error and stop the engine.
• CVE-2026-105753 (6.5). The mirrored multimodal cache could fall out of sync after a rejected request, so a later request reusing the same media hash tripped an assertion in the engine. Fixed in 0.28.0.
• CVE-2026-105754 (6.5). The disaggregated scale-out generate endpoint accepted caller-supplied multimodal features without rebinding them to the active model’s contract. The record says forged inputs could terminate the engine and, if an attacker knew or could induce a victim’s content hash, poison or read cross-request encoder-cache state.

Three more are resource-exhaustion bugs. CVE-2026-105758 (5.3) and CVE-2026-105760 (5.3) let request-level video options for the Qwen2-VL/Qwen3-VL and GLMGA backends push frame sampling far past sensible limits. The Qwen issue was reachable without authentication, and its record says the Rust frontend is not affected. CVE-2026-105759 (5.9) affects that Rust frontend instead: its metrics middleware recorded raw HTTP method tokens as Prometheus labels, so an unauthenticated caller could keep adding label sets until memory or the metrics path ran out.

Cracks in tenant isolation

The remaining two concern multi-tenant serving. vLLM’s cache_salt option keeps one tenant’s cached prefixes apart from another’s. CVE-2026-105752 (3.1) found that GPT-OSS Harmony tool continuations on /v1/responses dropped the salt on later turns. Those turns landed in the shared, unsalted cache, where another tenant who could reconstruct the history could learn from cached-token counts whether that prefix had been processed. Prefix caching is on by default. CVE-2026-105755 (4.2) found that late-interaction scoring on /score and /rerank keyed its query cache on the caller-controlled request ID, so a concurrent request reusing that ID could make the victim’s documents be scored against a different query.

What 0.31.0 changes

vLLM 0.31.0 was published on GitHub at 06:44 UTC on October 5. It includes 717 commits from 307 contributors, 96 of them new, and its notes include a dedicated security section. Per-request mm_processor_kwargs and media_io_kwargs are now rejected unless the server starts with --trust-request-mm-kwargs. That breaking change closes off the request field named in both video advisories. Prefix-cache keys are now tagged by source, so a LoRA name and a cache_salt can no longer collide, and the LoRA path is part of the block hash. Fresh multimodal payloads take precedence over stale receiver-cache entries, and a min_tokens value above the filled max_tokens default is rejected instead of wedging the engine.

For operators, the minimum is 0.30.0, and 0.31.0 is the current release on PyPI. Shared deployments are where the batch matters most: they should check whether they rely on cache_salt, LMCache-MP, structured output, or multimodal video inputs. They should also confirm that unauthenticated callers cannot reach tokenization and metrics routes.