EUVD-2026-92842
GHSA-935w-9g4m-p28p
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as co-tenant
-
DeliveryReconstruct victim's low-entropy post-tool history
-
ExploitSubmit matching Harmony continuation via POST /v1/responses
-
ExecutionRead returned cached_tokens_per_turn count
-
ImpactInfer victim prefix was cached, defeating isolation
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK
2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires: (1) prefix caching enabled, which is the default; (2) the caller having enabled cache_salt salting that this bug fails to preserve across Harmony tool continuations; (3) the attacker being an authenticated tenant on the same deployment (PR:L); and (4) the attacker's ability to reconstruct a victim's low-entropy post-tool conversation history to reproduce the continuation prefix. Exploitation occurs specifically through Harmony tool continuations submitted to POST /v1/responses, using the cached_tokens_per_turn response field as a hit/miss oracle. Limiting factors: authentication is required, success depends on the victim history being low-entropy and reconstructable (high complexity), and only the isolation property of salted prefix caching is affected - not direct content disclosure. Deployments without prefix caching or without reliance on cache_salt are not meaningfully exposed. |
| Impact | This is a genuine but low-severity, low-priority issue. The provided CVSS vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N, base ~3.1) correctly reflects a constrained threat: exploitation requires an authenticated tenant (PR:L) and high attack complexity (AC:H) because the attacker must independently reconstruct the victim's low-entropy post-tool conversation history before the cached_tokens_per_turn oracle reveals anything. No EPSS score, KEV listing, POC, or SSVC data was provided, so there is no signal of active or probable exploitation - consistent with 'no public exploit identified at time of analysis.' One notable discrepancy: the official vector scores this as an integrity impact (C:N/I:L) even though CWE-200 and the description describe an information-disclosure side channel that defeats tenant isolation; a confidentiality impact (C:L/I:N) is the more faithful mapping, though the resulting base score is similar. The practical outcome is a cache-timing oracle that confirms whether a prefix was previously processed - not direct content exfiltration - making this a privacy/isolation hardening fix rather than an urgent emergency. Verify tenancy model and whether salted prefix caching is actually relied upon before prioritizing. |
| Exploit ScenarioDerived | A multi-tenant vLLM deployment with the default prefix caching enabled hosts several customers who rely on cache_salt for isolation. A malicious authenticated tenant who can guess or reconstruct another tenant's short, predictable post-tool continuation submits the same Harmony tool continuation via POST /v1/responses and inspects the returned cached_tokens_per_turn value to confirm the victim's prefix was already processed and cached. No public exploit code is referenced. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
vLLM deployments prior to 0.30.0 with prefix caching enabled (the default) fail to carry the caller's cache_salt value across Harmony tool continuations submitted to "POST /v1/responses", so continuation prefixes land in the global unsalted prefix-cache namespace. This lets an authenticated tenant who can reconstruct a victim's low-entropy post-tool conversation history submit the same continuation and read the cached_tokens_per_turn counter as a hit/miss oracle, confirming whether that prefix was previously processed and thereby defeating salt-based tenant isolation of the cache. This is a genuine but low-severity, low-priority issue: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N, exploitation requires authenticated access, prefix caching to be on, cache_salt salting to be in use, and the victim's history to be low-entropy and reconstructable, and only the isolation property leaks - no direct model output or prompt content is disclosed. No public exploit code and no confirmed active exploitation were identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to vLLM 0.30.0, which preserves cache_salt across Harmony tool continuations; the fix is documented in the advisory at https://github.com/vllm-project/vllm/security/advisories/GHSA-935w-9g4m-p28p with code changes in pull requests 50195 and 51818 and commit 6a2a2bb02b563b83f946012959fd3927984d072a. If upgrading immediately is not possible, the most direct compensating control is to disable prefix caching on affected serving instances (for example via the --no-enable-prefix-caching flag), which removes the shared cache namespace that the cached_tokens_per_turn oracle observes at the cost of increased latency and reduced throughput for repeated-prefix workloads; alternatively, restrict access to the "/v1/responses" endpoint and specifically to tool-continuation flows so that only fully trusted, single-tenant callers can reach the affected code path, accepting that this breaks multi-tenant use of that API. Because exploitation requires an authenticated tenant plus a low-entropy, reconstructable victim history, tightening authentication and segregating tenants onto separate vLLM instances or processes is a further useful boundary, though it carries higher operational overhead than disabling prefix caching. Any remaining deployment that both enables prefix caching and depends on cache_salt for isolation should be treated as unmitigated until it runs 0.30.0 or later.
Affected VersionsENISA
Affected Packages
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 OpenAI-compatible "/v1/responses" endpoint supports tool calling via the OpenAI Harmony format. When prefix caching is enabled (the default on deployments serving LLMs), the engine reuses previously computed KV-cache blocks for shared prompt prefixes; the cache_salt parameter is the mechanism intended to partition that cache per tenant so one caller's salted prefix cannot be matched or reused by another. The bug (CWE-200, Exposure of Sensitive Information) is that rebuild of the next-turn engine input for Harmony tool continuations drops the cache_salt attribute, so the continuation prefix is stored and looked up in the global unsalted namespace instead of the caller's salted namespace. Because the response exposes cached_tokens_per_turn, an attacker gains a boolean-style side channel: a non-zero cache hit reveals that an identical prefix was processed earlier by someone else. The root cause class is improper handling of a security-scoping attribute during request reconstruction, not a memory-safety or injection flaw, which matches the assessed low confidentiality-only impact (C:L, I:N, A:N) and the AC:H rating reflecting the reconstruction prerequisite. Code references in the fix touch the Responses render path and request/tool-continuation construction (docs/serving/online_serving/renderer.md, vllm/entrypoints/openai/responses/context.py, and the online renderer), which is consistent with the salt being lost while rebuilding Harmony-tool conversation state. Per the CPE cpe:2.3:a:vllm-project:vllm:*:*:*:*:*:*:*:*, all vLLM releases before 0.30.0 are in scope.
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
AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
Authenticated tenant (PR:L), network API (AV:N); AC:H because the victim's low-entropy history must be reconstructed; the leak is a confidentiality oracle so C:L, with I/A none.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, Harmony tool continuations submitted through "POST /v1/responses" requests rebuild the next-turn engine input without preserving the cache_salt value, placing the continuation prefix in the global unsalted cache namespace even when the caller enabled salting. On deployments with prefix caching enabled, which is the default, an authenticated tenant who can reconstruct a victim's low-entropy post-tool history can submit the same continuation and use the cached_tokens_per_turn count to determine whether the prefix was previously processed, defeating the intended tenant isolation of salted prefix caching. This issue is fixed in version 0.30.0.
Blast Radius
ecosystem impact- 4 pypi packages depend on vllm (4 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.30.0.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Exploit-DB