VLLM · GHSA-v97p-wpxp-px84 · AI agents & MCP
FIX → 0.21.0
When vLLM's V1 model runner uses async scheduling with pipeline parallelism, stale token data from one user's earlier request can be fed into another user's batch slot. The contamination can then appear in the other user's model output.
first public Nov 9, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Deployments of vLLM from 0.16.0 through 0.20.2 that use the V1 model runner with async scheduling and pipeline parallelism (pipeline_parallel_size > 1) are exposed, especially multi-tenant inference serving where users submit private prompts. Single-GPU or non-pipeline-parallel deployments, and deployments with async scheduling turned off, are not affected according to the advisory's root cause.
Not affected if default-config, no-async-scheduling, pipeline-parallel-size-1, single-tenant
Who cares llm-serving, multi-tenant, python, vllm
pip show vllm; affected versions are >= 0.16.0 and < 0.21.0.--no-async-scheduling and pipeline_parallel_size settings in the vLLM launch command or config; the issue needs async scheduling and .When the V1 model runner uses async scheduling with pipeline parallelism (pipeline_parallel_size > 1), token data from a previous user's request context can leak into another user's response.
A detailed technical analysis has been reported in https://github.com/vllm-project/vllm/issues/38903#issue-4199660402.
Affected versions: v0.16.0 through v0.20.2 when using the V1 model runner with async scheduling and pipeline parallelism.
Patched version: v0.21.0.
Root cause: On non-last pipeline ranks during async scheduling, token_ids_cpu is never written with generated tokens, and num_tokens_no_spec is incorrectly reset each step. When the token_ids_cpu fallback path is triggered (e.g., mixed prefill/decode batches), stale token data from a previous request occupying the same batch slot is read as model input and written into the KV cache, permanently contaminating the response.
This constitutes a cross-user data leak in multi-tenant inference deployments. In environments where users submit sensitive or private prompts (e.g., personal information, proprietary business data, medical or legal content), fragments of one user's context can influence or appear in another user's output.
For deployments on affected versions, either of these settings mitigates the issue.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
pipeline_parallel_size > 1Upgrade to 0.21.0
0.21.0 or later.--no-async-scheduling, or set pipeline_parallel_size=1.--no-async-schedulingpipeline_parallel_size=1 (disabling pipeline parallelism)A fix for this was introduced in https://github.com/vllm-project/vllm/pull/41133.