Skip to main content

vLLM CVE-2026-105755

MEDIUM
Authorization Bypass Through User-Controlled Key (CWE-639)
2026-10-05 GitHub_M GHSA-2phq-3phc-84px
4.2
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain low-privilege API access to /score or /rerank
  2. Exploit
    Reuse a victim's X-Request-Id header
  3. Execution
    Win cache-key race with a concurrent request
  4. Impact
    Overwrite cached query embedding, corrupting victim scoring

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
Exploitation Conditions

Requires a vLLM deployment (prior to 0.30.0) that exposes the flash late-interaction scoring path via the /score or /rerank endpoints, and a shared/multi-tenant context where multiple callers' requests are processed concurrently. The attacker must be able to send API requests (PR:L) and must set the X-Request-Id header to collide with a victim's in-flight request, then win a concurrency race (AC:H) against the victim's query-embedding cache write. Exploitation is LIMITED by: the narrow timing window of the race, the need to know or predict a victim's X-Request-Id, the requirement that the late-interaction scoring feature actually be in use, and the lack of value in single-tenant deployments. No special user interaction is needed.

Impact

This is a low-to-moderate priority issue despite the 'Authentication Bypass' tag. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L) scores 4.2 (Medium) and is internally consistent with the description: network-reachable but requiring high attack complexity (the attacker must win a race against a concurrent victim request reusing the same X-Request-Id), low privileges (ability to send /score or /rerank API requests), and no confidentiality impact - only integrity (victim documents scored against the attacker's query) and availability (shared use-counter late-interaction cache-miss errors). CWE-639 (Authorization Bypass Through User-Controlled Key) accurately captures the root cause: a caller-controlled header used as a cache namespace key. No EPSS score, no CISA KEV listing, and no public exploit were provided, so exploitation status is 'no public exploit identified at time of analysis'. The practical risk is confined to multi-tenant or shared vLLM scoring/rerank deployments; single-tenant deployments have little exposure because an attacker colliding with their own request IDs gains nothing. Note the tag 'Authentication Bypass' overstates the issue - this is an authorization/IDOR-style cache-key collision, not a bypass of authentication, and the attacker still needs valid API access (PR:L).

Exploit ScenarioDerived

On a shared or multi-tenant vLLM server exposing the /score or /rerank late-interaction endpoints, an authenticated attacker observes or guesses a victim's X-Request-Id and fires a concurrent request reusing that identifier. Winning the race overwrites the cached query embedding, so the victim's documents are silently scored against the attacker's query (integrity corruption) or the shared use counter triggers a cache-miss error (availability). No public exploit code was identified; the attack requires precise concurrency timing (AC:H).

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 05, 2026

vLLM versions prior to 0.30.0 derive the flash late-interaction query-cache key from the caller-controlled X-Request-Id header, so an authenticated API caller on a shared deployment can collide with a victim's in-flight request and cause the victim's documents to be scored against the attacker's query through the /score and /rerank endpoints, while shared use counters can also give rise to a late-interaction cache-miss error. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L (base 4.2), reflecting a narrow concurrency race that requires knowledge of or a lucky guess at the victim's request identifier, and no confidentiality impact; there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV). The issue is fixed in vLLM 0.30.0, and the practical risk is confined to multi-tenant or otherwise shared deployments that actually enable the flash late-interaction scoring path.

RemediationAI

Vendor-released patch: upgrade to vLLM 0.30.0 (or later), which replaces the caller-controlled query key with a random_uuid-based namespace and validates that query keys are initialized before document encoding; the change is tracked in GHSA-2phq-3phc-84px (https://github.com/vllm-project/vllm/security/advisories/GHSA-2phq-3phc-84px) and implemented by PR https://github.com/vllm-project/vllm/pull/51445 (commit ee17d0d869203ef9a35ad73358a4987bba14b1fc), so upgrading is the only complete fix and any backport must carry that commit rather than merely filtering headers. If upgrading is not immediately possible, the most reliable compensating control is to stop exposing the flash late-interaction scoring path: disable late-interaction scoring or remove /score and /rerank from externally reachable routes and keep them behind an authenticated internal gateway, accepting the trade-off that this removes a legitimate feature for external consumers. Because the vulnerability only manifests when multiple callers share one scoring process, moving untrusted tenants onto separate vLLM deployments (per-tenant instances or processes) removes the cross-request cache collision entirely, at the cost of higher GPU memory and operational overhead; conversely, a reverse proxy that strips or rewrites X-Request-Id reduces the attacker's control over the cache key but cannot be considered a complete fix unless the server falls back to a random per-request identifier, and it may break client-side request tracing that depends on that header. Rate-limiting or serializing concurrent scoring requests reduces the feasibility of winning the race but degrades throughput for legitimate traffic, and monitoring for duplicate or suspicious X-Request-Id values and late-interaction cache-miss errors provides detection rather than prevention.

Affected Packages

pypi vllm fix: 0.30.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in pypi

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

vLLM is an inference and serving engine for large language models, and its pooling/scoring entrypoint implements ColBERT-style late-interaction scoring in which query token embeddings are encoded once and cached under a query_key so that document scoring can reuse them. Before 0.30.0, the flash late-interaction path in vllm/entrypoints/pooling/scoring/serving.py built that key as f"{ctx.request_id}-query-{i}", and ctx.request_id is populated from the caller-supplied X-Request-Id header, making the cache namespace a user-controlled value - the classic CWE-639 (Authorization Bypass Through User-Controlled Key) pattern. Because the key is shared across requests handled by the same process, a second request that reuses a victim's identifier can overwrite the cached query embedding, so the victim's documents are subsequently scored against the attacker's query (integrity impact) and the shared use counters for that key can desynchronize, producing a late-interaction cache-miss error (availability impact). The patch (PR #51445, commit ee17d0d869203ef9a35ad73358a4987bba14b1fc) replaces the request-derived key with a per-request random_uuid namespace (f"late-interaction-{query_namespace}-query-{i}"), stores the generated keys on the request context as late_interaction_query_keys, and raises a RuntimeError if the document-encoding step runs before the query keys are initialized, with a regression test asserting that colliding request IDs now yield distinct, non-caller-controlled cache keys.

Know when Vllm gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 4.2 MEDIUM
AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L
vuln.today AI 4.2 MEDIUM

Network-reachable endpoint (AV:N) but requires winning a concurrency race with a colliding request ID (AC:H) and valid API access (PR:L); only result integrity and cache availability are affected, no data disclosure (C:N/I:L/A:L).

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L
4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
Red Hat 4.2 MEDIUM

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
Low

DescriptionCVE.org

vLLM is an inference and serving engine for large language models. Prior to 0.30.0, flash late-interaction scoring at the /score and /rerank endpoints derives each worker's query_key value from the caller-controlled X-Request-Id header. A concurrent request that reuses a victim's identifier can overwrite the cached query embedding so the victim's documents are scored against the attacker's query, and shared use counters can also cause a late-interaction cache-miss error. This issue is fixed in version 0.30.0.

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 4 pypi packages depend on vllm (4 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.30.0.

Threat Intelligence Overview

EPSS Score
0.2%
Top 91% exploitable
Prevalence
Medium
popular LLM serving engine, but niche late-interaction scoring feature and shared deployments
Threat Intel
1
1 source
Social Media
1
Sightings
Data Quality
5 sources
Confidence: Medium
🇯🇵JVN NVD CVE.org EPSS Vulnrichment GHSA Vendor CIRCL GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

21
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +21
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Affected Products (CPE)CVE.org

cpe:2.3:a:vllm-project:vllm:*:*:*:*:*:*:*:*

More in Vllm

View all
CVE-2025-32444 CRITICAL POC
10.0 Apr 30

vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0

CVE-2024-11041 CRITICAL POC
9.8 Mar 20

vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev

CVE-2026-22778 CRITICAL POC
9.8 Feb 02

Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal

CVE-2025-59425 HIGH POC
7.5 Oct 07

Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de

CVE-2025-30202 HIGH POC
7.5 Apr 30

vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th

CVE-2026-54234 HIGH POC
7.5 Jul 06

Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh

CVE-2026-24779 HIGH POC
7.1 Jan 27

vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons

CVE-2026-57173 MEDIUM POC
6.5 Sep 16

Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat

CVE-2025-46560 MEDIUM POC
6.5 Apr 30

vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),

CVE-2026-69147 MEDIUM POC
6.5 Sep 16

GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS

CVE-2026-105753 MEDIUM POC
6.5 Oct 05

Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion

CVE-2026-73559 MEDIUM POC
6.5 Aug 13

Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t

Vendor StatusVendor

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy