CVE-2026-114049: vLLM before 0.31.0 Stale allowed_token_ids Mask via InputBatch.condense

Q: Who is exposed to this issue?

Deployments running vLLM before 0.31.0 are exposed when they process concurrent generation requests. The risk is especially relevant for services exposing an unauthenticated /invocations endpoint, because an unauthenticated remote attacker can submit constrained requests.

Q: What must an attacker do to exploit it?

An attacker must submit concurrent constrained generation requests that use allowed_token_ids. By leaving stale allowlist rows in recycled batch slots, the attacker can cause a victim's otherwise unrestricted request to inherit token restrictions.

Q: What is the impact on affected requests?

The issue affects output integrity: a victim's generated output can be constrained by an allowlist chosen by another client. The provided severity vector indicates no confidentiality or availability impact.

Q: What should be done if an immediate upgrade is not possible?

The provided data identifies concurrent constrained requests, including requests through unauthenticated /invocations, as the exploitation path. Restricting access to that endpoint and avoiding or tightly controlling concurrent requests using allowed_token_ids can reduce exposure until vLLM is updated to 0.31.0 or later.

Published Oct 21, 2026

Updated

vLLM before 0.31.0 contains a cross-request mask leak in InputBatch.condense() that allows remote attackers to constrain other clients' outputs by leaving stale allowedtokenids rows. Attackers can submit concurrent constrained generate requests, including via unauthenticated /invocations, so recycled batch slots apply their token allowlist to victims' unrestricted requests.

Affected Software

1 affected component

vllm vllm<0.31.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade vLLM to a version that resolves this vulnerability.
Fixed in 0.31.0

Event History

Oct 21, 2026

CVE Published

via MITRE·12:36 AM

Data Sourced

via MITRE·12:36 AM

DescriptionSeverityWeakness

Frequently Asked Questions

Who is exposed to this issue?

Deployments running vLLM before 0.31.0 are exposed when they process concurrent generation requests. The risk is especially relevant for services exposing an unauthenticated /invocations endpoint, because an unauthenticated remote attacker can submit constrained requests.

What must an attacker do to exploit it?

An attacker must submit concurrent constrained generation requests that use allowed_token_ids. By leaving stale allowlist rows in recycled batch slots, the attacker can cause a victim's otherwise unrestricted request to inherit token restrictions.

What is the impact on affected requests?

The issue affects output integrity: a victim's generated output can be constrained by an allowlist chosen by another client. The provided severity vector indicates no confidentiality or availability impact.

What should be done if an immediate upgrade is not possible?

The provided data identifies concurrent constrained requests, including requests through unauthenticated /invocations, as the exploitation path. Restricting access to that endpoint and avoiding or tightly controlling concurrent requests using allowed_token_ids can reduce exposure until vLLM is updated to 0.31.0 or later.

CVE-2026-114049: vLLM before 0.31.0 Stale allowed_token_ids Mask via InputBatch.condense

Affected Software

Remediation

Event History

Frequently Asked Questions

Who is exposed to this issue?

What must an attacker do to exploit it?

What is the impact on affected requests?

What should be done if an immediate upgrade is not possible?

Company

Resources

Contact

Frequently Asked Questions

Who is exposed to this issue?

What must an attacker do to exploit it?

What is the impact on affected requests?

What should be done if an immediate upgrade is not possible?