CVE-2026-114054: vLLM cache aliasing leaks

CISO Take

vLLM before 0.31.0 lets an authenticated user collide shared cache keys by supplying caller-controlled values such as a UUID EXIF ImageID or a cache_salt that matches a LoRA name. This can cause one tenant's request to receive another request's cached processed media, or to reuse first-block KV state. The scored impact is availability (CVSS 6.5, medium), but the practical risk in multi-tenant inference is cross-tenant integrity and confidentiality exposure, which makes it relevant to shared LLM gateways. There is no KEV listing, no public exploit and no Nuclei template, and EPSS is not yet available, so near-term mass exploitation looks unlikely; attacks need only low privileges, though, and the technique is simple. Upgrade to vLLM 0.31.0 or later, and until then avoid sharing a vLLM instance across trust boundaries and do not pass untrusted cache_salt or image metadata through to the engine.

Sources:NVDGitHub Advisoryvulncheck.comATLAS

What is the risk?

Medium overall. Exploitation is network-reachable, low complexity, needs low privileges and no user interaction. NVD scores the impact as availability only, but the mechanism (shared cache key collisions) can also corrupt integrity and expose another request's cached data in multi-tenant deployments. No known exploitation, no public exploit and no KEV listing. Exposure is highest for shared inference endpoints that serve multiple customers or teams and accept multimodal inputs or per-request cache_salt values. Single-tenant, internally authenticated deployments carry low risk.

How does the attack unfold?

Initial Access

Attacker authenticates to a shared vLLM inference endpoint with a low-privilege account or API key.

AML.T0040

Exploitation

Attacker supplies a UUID EXIF ImageID or a cache_salt matching a LoRA name to collide with shared cache keys.

AML.T0049

Impact

The engine returns another request's cached processed media or reuses its first-block KV state, leaking or corrupting cross-request data and degrading service.

AML.T0057

Initial Access

Attacker authenticates to a shared vLLM inference endpoint with a low-privilege account or API key.

AML.T0040

Exploitation

Attacker supplies a UUID EXIF ImageID or a cache_salt matching a LoRA name to collide with shared cache keys.

AML.T0049

Impact

The engine returns another request's cached processed media or reuses its first-block KV state, leaking or corrupting cross-request data and degrading service.

AML.T0057

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
95.4K94 dependentsPushed 6d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 20% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to 0.31.0 or later. 2) Until patched, do not co-host mutually untrusted tenants on one vLLM instance; use separate instances or deployments per trust boundary. 3) Strip or rewrite client-supplied cache_salt values at the gateway and generate them server-side per tenant with high-entropy values. 4) Sanitize or strip EXIF metadata, including ImageID, from uploaded images before they reach the engine. 5) Where feasible, disable prefix caching and the multimodal processor cache for multi-tenant workloads. 6) Detection: log and alert on requests with UUID-formatted EXIF ImageIDs, cache_salt values that equal known LoRA adapter names, and unusual cache hit patterns or anomalous responses for a single tenant. 7) Review the GitHub advisory GHSA-rh6f-3x46-j33q and the VulnCheck advisory for details.

How is it classified?

Data LeakageAuth BypassInferenceFrameworkAML.T0040- AI Model Inference API Access AML.T0049- Exploit Public-Facing Application AML.T0057- LLM Data Leakage

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responses to previously unknown risks and mechanisms to supersede or deactivate AI systems

OWASP LLM Top 10

LLM02-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-114054?

vLLM before 0.31.0 lets an authenticated user collide shared cache keys by supplying caller-controlled values such as a UUID EXIF ImageID or a cache_salt that matches a LoRA name. This can cause one tenant's request to receive another request's cached processed media, or to reuse first-block KV state. The scored impact is availability (CVSS 6.5, medium), but the practical risk in multi-tenant inference is cross-tenant integrity and confidentiality exposure, which makes it relevant to shared LLM gateways. There is no KEV listing, no public exploit and no Nuclei template, and EPSS is not yet available, so near-term mass exploitation looks unlikely; attacks need only low privileges, though, and the technique is simple. Upgrade to vLLM 0.31.0 or later, and until then avoid sharing a vLLM instance across trust boundaries and do not pass untrusted cache_salt or image metadata through to the engine.

Is CVE-2026-114054 actively exploited?

No confirmed active exploitation of CVE-2026-114054 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-114054?

1) Upgrade vLLM to 0.31.0 or later. 2) Until patched, do not co-host mutually untrusted tenants on one vLLM instance; use separate instances or deployments per trust boundary. 3) Strip or rewrite client-supplied cache_salt values at the gateway and generate them server-side per tenant with high-entropy values. 4) Sanitize or strip EXIF metadata, including ImageID, from uploaded images before they reach the engine. 5) Where feasible, disable prefix caching and the multimodal processor cache for multi-tenant workloads. 6) Detection: log and alert on requests with UUID-formatted EXIF ImageIDs, cache_salt values that equal known LoRA adapter names, and unusual cache hit patterns or anomalous responses for a single tenant. 7) Review the GitHub advisory GHSA-rh6f-3x46-j33q and the VulnCheck advisory for details.

What systems are affected by CVE-2026-114054?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, multimodal pipelines, multi-tenant inference gateways, LoRA adapter serving.

What is the CVSS score for CVE-2026-114054?

CVE-2026-114054 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.27%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inferencemultimodal pipelinesmulti-tenant inference gatewaysLoRA adapter serving

MITRE ATLAS Techniques

AML.T0040AI Model Inference API Access

AML.T0049Exploit Public-Facing Application

AML.T0057LLM Data Leakage

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

vLLM before 0.31.0 contains a cache aliasing vulnerability that allows authenticated attackers to collide shared cache keys by supplying caller-controlled values such as EXIF ImageID or cache_salt. Attackers can set a UUID EXIF ImageID to receive another request's cached processed media, or match cache_salt to a LoRA name to reuse first-block KV state.

Exploitation Scenario

An attacker with a low-privilege API key on a shared vLLM-based inference service learns or guesses the UUID that identifies another tenant's image, for example from metadata in a shared document workflow. They upload an image whose EXIF ImageID is set to that UUID, and the engine returns the other request's cached processed media instead of processing the attacker's input, so responses are built on content the attacker does not own. In a second variant, the attacker sets cache_salt to the name of a LoRA adapter so their prompt collides with first-block KV state from other requests, reusing cached state across the isolation boundary and degrading or influencing outputs.

Weaknesses (CWE)

CWE-284Improper Access ControlPrimary CWE-284Improper Access Control

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.