Two vLLM advisories let one request's output leak into another

What changed

On 9 November 2026, two security advisories were published for vLLM. Both describe ways the output of one request can end up in another request being served at the same time. A third-party GitHub repository that tracks AI-stack advisories added them on 10 November. Neither has a CVE ID, and each applies only when an optional feature is turned on.

The first, GHSA-fpch-3xrf-7q96, is rated Medium (CVSS 5.3). It applies when reasoning is enabled and reasoning_end_str is configured. A client that sets the thinking_token_budget sampling parameter can cause the reasoning-end string to be inserted into another concurrent request's output when the batch is reordered.

For the second, the listed workaround on affected versions is --no-async-scheduling or pipeline_parallel_size=1. The copy I read was truncated, so I do not have its ID or full description. I would confirm both advisories on vLLM's own GitHub security page rather than rely on the tracker alone.

vLLM 0.33.0 is affected by neither. Users still on 0.16 to 0.27 had already been told to upgrade by earlier advisories, such as GHSA-5r3c-5x4v-8gjh, which is fixed in 0.33.0.

Why it matters for builders

Most of the isolation in agent systems lives above the model server: per-tenant retrieval filters, scoped tools, separate memory. These advisories sit below all of that. When several users or agents share one vLLM instance, the batch is a shared resource, and a scheduling bug can put text from one request into another's response. No permission check upstream will see it happen.

The severity rating is moderate, but the shape is what concerns me. One client controls a sampling parameter, and a different request's output changes. In an agent loop that output may be parsed for a tool call or written into memory, so even a stray marker string could do more than look odd.

The second problem is detection. Neither advisory had an OSV.dev record when checked on 10 November, so most dependency scanners will not report them. A clean scan here means the database is behind, not that the deployment is safe.

What I would do with it

I would treat this as an inventory and isolation exercise rather than a single patch.

• List every vLLM instance with its version and launch flags, including internal tools nobody thinks of as production.
• Upgrade to 0.33.0. Anything on 0.16 to 0.27 was already overdue.
• If an upgrade has to wait, check whether reasoning with reasoning_end_str is configured and whether async scheduling or pipeline parallelism is in use, and apply the listed workaround where it fits.
• Treat sampling parameters as untrusted input. I prefer an allowlist at the gateway, so a client cannot pass thinking_token_budget or anything else the server did not plan for.
• Add a concurrency canary test: send many simultaneous requests, each told to echo a unique marker, and assert that no marker shows up in another response. It is cheap to keep in CI and catches this whole class of bug, not just these two.

Finally, I would subscribe to vLLM's security advisories directly. For inference servers, scanners are a backstop, not the alert.

A shared inference server is a multi-tenant system, so its batch scheduler belongs in your isolation model and its advisories need someone watching the source, not just a scanner.

Sources

• Release v1.2.6: two vLLM cross-request advisories · munimtechnologies/ai-stack-advisories · GitHub