---
id: "GHSA-v97p-wpxp-px84"
page: "https://infrastack.ai/live/GHSA-v97p-wpxp-px84"
kind: "vulnerability"
aliases: ["GHSA-v97p-wpxp-px84"]
title: "Cross-user token data leakage in async scheduling + Pipeline Parallelism"
severity: "medium"
cvss: 4.8
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "vllm", "fixed": ["0.21.0"], "affected": ">= 0.16.0, < 0.21.0", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-tooling", "llm-serving", "multi-tenant", "python", "vllm"]
not_affected_if: ["default-config", "no-async-scheduling", "pipeline-parallel-size-1", "single-tenant"]
published_at: "2026-11-09T17:29:51+00:00"
first_seen_at: "2026-11-09T22:53:23+00:00"
updated_at: "2026-11-09T22:57:02+00:00"
sources: [{"source": "ghsa-repo", "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-v97p-wpxp-px84", "first_seen_at": "2026-11-09T22:53:23+00:00"}]
exploit_sources: []
---

# Cross-user token data leakage in async scheduling + Pipeline Parallelism

Link for people: https://infrastack.ai/live/GHSA-v97p-wpxp-px84 (this .md is for agents)

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.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:vllm affected >= 0.16.0, < 0.21.0 fixed 0.21.0

## How to check

- Check the installed vLLM version with `pip show vllm`; affected versions are `>= 0.16.0` and `< 0.21.0`.
- Look for `--no-async-scheduling` and `pipeline_parallel_size` settings in the vLLM launch command or config; the issue needs async scheduling and `pipeline_parallel_size > 1`.

## Fix

- vLLM: move to `0.21.0` or later.
- Workaround from the advisory until upgraded: launch with `--no-async-scheduling`, or set `pipeline_parallel_size=1`.

## Timeline

- 2026-11-09T22:53:23+00:00 ghsa-repo https://github.com/vllm-project/vllm/security/advisories/GHSA-v97p-wpxp-px84

## Documents

- [advisory] Maintainer's advisory: github.com https://github.com/vllm-project/vllm/security/advisories/GHSA-v97p-wpxp-px84

## From the sources

### Summary
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.

### Details
**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.

### Impact
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.

### Workaround
For deployments on affected versions, either of these settings mitigates the issue.

- Launching vLLM with `--no-async-scheduling`
- Setting `pipeline_parallel_size=1` (disabling pipeline parallelism)

A fix for this was introduced in https://github.com/vllm-project/vllm/pull/41133.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_