CVE-2026-114049 in vLLM
Summary
by MITRE • 10/22/2026
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 allowed_token_ids rows. Attackers can submit concurrent constrained generate requests, including via unauthenticated /invocations, so recycled batch slots apply their token allowlist to victims' unrestricted requests.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in vLLM versions prior to 0.31.0 represents a critical security flaw within the InputBatch.condense() method, specifically manifesting as a cross-request mask leak. This issue stems from improper state management during batch processing and recycling of computational slots. In large language model serving systems like vLLM, efficiency is achieved by batching multiple inference requests together to maximize GPU utilization. When a request completes or is cancelled, its allocated slot in the computation batch is often recycled for subsequent incoming requests to minimize overhead. However, in this specific implementation, the mechanism responsible for cleaning up these slots fails to fully reset all associated metadata fields before reuse.
The core technical flaw lies in the handling of allowed_token_ids, which defines a constrained set of tokens that the model is permitted to generate next. This feature is commonly used by developers to enforce output formats or restrict vocabulary. When an attacker submits a request with such constraints and then terminates it prematurely or allows it to complete while leaving residual state, the associated token allowlist remains attached to the recycled batch slot. Because vLLM reuses these slots for new incoming requests without clearing this specific field, any subsequent victim request assigned to that same slot inherits the stale allowed_token_ids configuration from the previous attacker-controlled session.
This leads to a severe operational impact where remote attackers can effectively constrain or poison the outputs of other clients sharing the same inference infrastructure. By submitting concurrent constrained generate requests via unauthenticated endpoints such as /invocations, an attacker ensures that their malicious batch slot is recycled at precisely the moment another user submits an unrestricted request. The victim's request then inherits the attacker's token restrictions, potentially causing generation failures if the required tokens are excluded from the allowed list, or producing biased and incorrect outputs by artificially limiting the model's vocabulary space. This constitutes a form of denial-of-service through output manipulation, as well as a potential data integrity issue depending on the application context.
From a classification perspective, this vulnerability aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, specifically regarding the leakage of configuration state between isolated sessions. It also maps to MITRE ATT&CK technique T1498: Network Denial of Service, as it degrades service quality for legitimate users by corrupting their inference results. Furthermore, it reflects CWE-665: Improper Initialization, highlighting a failure in properly resetting object states before reuse in multi-tenant environments.
Mitigation strategies must focus on ensuring strict isolation between concurrent requests and rigorous state cleanup during resource recycling. The primary fix involves modifying the InputBatch.condense() method to explicitly clear all mutable metadata fields, including allowed_token_ids, when a batch slot is marked for reuse or deallocation. Developers should implement defensive programming practices that assume any reused memory or object state may contain residual data from previous operations. Additionally, enforcing authentication on inference endpoints reduces the attack surface by preventing unauthenticated actors from triggering these malicious sequences. Upgrading to vLLM version 0.31.0 or later resolves this issue as it includes patches for proper state isolation and cleanup procedures within the batching engine.