vLLM’s Insecure Serialization Flag Was Never the Door. A Shared Memory Handle Was.

A shared memory handle is two integers. An address and a counter. vLLM’s multimodal cache treats that pair as permission to read memory in the worker process, and a public request is allowed to supply its own.

That is the whole vLLM vulnerability. CVE-2026-115912 carries a CVSS score of 7.5 and was published to the GitHub Advisory Database on 28 October 2026, one of eight vLLM advisories that landed together and all of which are fixed in version 0.32.0. It is the one to read first, because the mitigation most teams would reach for does not apply to it.

The flag everyone turns off does not cover this

vLLM ships an option called insecure serialization, and turning it off is the standard hardening line in every deployment guide. It does nothing here. The advisory states the chain works with that flag at zero, because it abuses the shared memory object deserializer that is always on rather than the optional msgpack hook.

The precondition is narrower than it looks and wider than it sounds. The cache has to be running as shared memory, which is the –mm-processor-cache-type shm setting, and that mode exists to let multiple workers reuse one expensive image or audio preprocess. Any deployment that switched it on to cut preprocessing time is in scope. The reporter’s chain used /v1/chat/completions/render to obtain a valid feature envelope, /v1/chat/completions to stage chosen bytes into the buffer, then /inference/v1/generate to submit the forged carrier.

What lands is Python execution in the process serving the model. Not a container escape, still the worst place to lose, because that process can read the weights, the tokenizer, any mounted credentials and the inference traffic passing through it.

The second advisory is a plainer version of the same lesson. CVE-2026-115915 scores 8.1 because vLLM’s image loader passes attacker bytes to Pillow’s format detection without constraining the accepted formats, and an EPS payload labelled as a PNG reached the host Ghostscript. On a host with a vulnerable Ghostscript build that is a known sandbox escape. The request’s declared MIME type did not decide the decoder, which is the detail worth remembering.

The fix is upstream, which is not the same as your build being fixed

All eight are closed by pull request 59357 and ship in the 0.32.0 release. The advisory range is every version below that.

Here is the operational gap. Most teams do not run upstream vLLM. They run it inside a serving platform, a vendor distribution or an air gapped bundle rebuilt on a slower cadence. Those builds carry the platform’s version number, not vLLM’s, so the string in your manifest tells you nothing about which advisories are closed. Check the advisory identifier against the build you actually deploy, and ask the vendor for the commit rather than the version.

Do this too. Grep every serving manifest for the shared memory cache argument. Deployments that never enabled it are out of scope for the worst one. Deployments that did should treat the upgrade as a security patch rather than a routine bump, because the release also carries breaking changes to request handling that need a client test before rollout.

What to check this week

Start with the flag. If –mm-processor-cache-type shm appears anywhere in production, that deployment is one public request away from code execution on the host that holds your weights. The same class of flaw hit SGLang earlier this year when its cross request KV cache exposure let one tenant read another’s cached context. Serving engines keep finding the same soft spot, which is the boundary between what one request may write and what the worker will trust.

Then check the six quieter ones. A token id equal to the vocabulary size passes validation, goes unmasked when the vocabulary is a multiple of 64 and tensor parallelism is one, and kills the engine with a CUDA assertion. That is a denial of service from a single request, and it needs no authentication beyond whatever your endpoint already requires.

Three questions to take to your platform team. Which advisories does the build you run actually close, and who can show you the commit? Is multimodal preprocessing sharing memory across workers anywhere in the fleet? And when the next eight land in one afternoon, what is the process that turns an advisory into a rebuilt image before the weekend?