CVE-2026-93841
LOWvLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs index the penalty prompt-presence bitset without bounds checking against vocabulary size. Attackers can submit multimodal audio requests with tokens equal to vocabulary size, causing...
Full CISO analysis pending enrichment.
How severe is it?
What is the attack surface?
What should I do?
No patch available
Monitor for updates. Consider compensating controls or temporary mitigations.
Which compliance frameworks are affected?
Compliance analysis pending. Sign in for full compliance mapping when available.
Frequently Asked Questions
What is CVE-2026-93841?
vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs index the penalty prompt-presence bitset without bounds checking against vocabulary size. Attackers can submit multimodal audio requests with tokens equal to vocabulary size, causing out-of-bounds writes that corrupt concurrent requests' sampler state and alter repetition penalty behavior.
Is CVE-2026-93841 actively exploited?
No confirmed active exploitation of CVE-2026-93841 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-93841?
No patch is currently available. Monitor vendor advisories for updates.
What is the CVSS score for CVE-2026-93841?
CVE-2026-93841 has a CVSS v3.1 base score of 3.7 (LOW).
What are the technical details?
Original Advisory
vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs index the penalty prompt-presence bitset without bounds checking against vocabulary size. Attackers can submit multimodal audio requests with tokens equal to vocabulary size, causing out-of-bounds writes that corrupt concurrent requests' sampler state and alter repetition penalty behavior.
Weaknesses (CWE)
CWE-129 — Improper Validation of Array Index: The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
- [Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
- [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N References
- github.com/vllm-project/vllm
- github.com/vllm-project/vllm/blob/v0.29.0/vllm/v1/worker/gpu/sample/penalties.py
- github.com/vllm-project/vllm/blob/v0.29.0/vllm/v1/worker/gpu/sample/penalties.py
- github.com/vllm-project/vllm/pull/49081
- vulncheck.com/advisories/vllm-through-0.29.0-adjacent-request-sampler-state-corruption-via-unvalidated-prompt-token-ids