CVE-2026-105752: vLLM: cache_salt dropped on tool continuations leaks prefixes
GHSA-935w-9g4m-p28pLOWvLLM versions before 0.30.0 drop the per-tenant cache_salt when rebuilding Harmony tool continuations sent to POST /v1/responses, so those prefixes land in the global unsalted prefix cache and defeat tenant isolation. An authenticated tenant who can guess a victim's low-entropy post-tool history can submit the same continuation and read the cached_tokens_per_turn count to confirm whether it was previously processed, which is a narrow side-channel confirmation oracle rather than a direct data dump. Real-world urgency is low: CVSS is 3.1 with high attack complexity, EPSS is 0.00213 (89th percentile relative ranking, still tiny in absolute terms), there is no public exploit, no Nuclei template and no KEV listing. It still matters for multi-tenant AI gateways because vLLM has 95 downstream dependents and 134 other tracked CVEs, and prefix caching is on by default. Upgrade to vLLM 0.30.0 in the next regular patch cycle, and prioritize multi-tenant deployments that rely on cache_salt for isolation.
What is the risk?
Low overall. CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/C:N/I:L/A:N) reflects that exploitation needs authenticated access and a difficult-to-satisfy precondition: the attacker must reconstruct the victim's exact post-tool history, which only works when that content is predictable or low-entropy. The result is a one-bit confirmation (cache hit or miss) per guess, not arbitrary data disclosure. EPSS is 0.00213 and there is no public exploit, scanner template or KEV listing. Risk rises for multi-tenant LLM platforms that sell isolation guarantees, handle regulated data, or run agentic workloads whose tool outputs follow predictable templates (e.g., standard API responses, fixed-format records). Single-tenant or internal-only deployments are effectively unaffected.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | < 0.30.0 | 0.30.0 |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vLLM to 0.30.0 or later (fix in PR #50195/#51818, commit 6a2a2bb). 2) Until patched, in multi-tenant environments either disable prefix caching (--no-enable-prefix-caching) for workloads using /v1/responses with tool continuations, or isolate tenants onto separate vLLM instances. 3) Stop returning cached_tokens or per-turn usage details to untrusted tenants by stripping these fields at the API gateway. 4) Rate-limit and monitor per-tenant request patterns for repeated near-identical continuation requests that differ only in small guessed segments. 5) Inventory which services use Harmony tool continuations and cache_salt so patch priority can be set. 6) Track GHSA-935w-9g4m-p28p for any follow-up advisories.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-105752?
vLLM versions before 0.30.0 drop the per-tenant cache_salt when rebuilding Harmony tool continuations sent to POST /v1/responses, so those prefixes land in the global unsalted prefix cache and defeat tenant isolation. An authenticated tenant who can guess a victim's low-entropy post-tool history can submit the same continuation and read the cached_tokens_per_turn count to confirm whether it was previously processed, which is a narrow side-channel confirmation oracle rather than a direct data dump. Real-world urgency is low: CVSS is 3.1 with high attack complexity, EPSS is 0.00213 (89th percentile relative ranking, still tiny in absolute terms), there is no public exploit, no Nuclei template and no KEV listing. It still matters for multi-tenant AI gateways because vLLM has 95 downstream dependents and 134 other tracked CVEs, and prefix caching is on by default. Upgrade to vLLM 0.30.0 in the next regular patch cycle, and prioritize multi-tenant deployments that rely on cache_salt for isolation.
Is CVE-2026-105752 actively exploited?
No confirmed active exploitation of CVE-2026-105752 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-105752?
1) Upgrade vLLM to 0.30.0 or later (fix in PR #50195/#51818, commit 6a2a2bb). 2) Until patched, in multi-tenant environments either disable prefix caching (--no-enable-prefix-caching) for workloads using /v1/responses with tool continuations, or isolate tenants onto separate vLLM instances. 3) Stop returning cached_tokens or per-turn usage details to untrusted tenants by stripping these fields at the API gateway. 4) Rate-limit and monitor per-tenant request patterns for repeated near-identical continuation requests that differ only in small guessed segments. 5) Inventory which services use Harmony tool continuations and cache_salt so patch priority can be set. 6) Track GHSA-935w-9g4m-p28p for any follow-up advisories.
What systems are affected by CVE-2026-105752?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, multi-tenant LLM gateways, agent frameworks, tool-calling pipelines.
What is the CVSS score for CVE-2026-105752?
CVE-2026-105752 has a CVSS v3.1 base score of 3.1 (LOW). The EPSS exploitation probability is 0.22%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0024Exfiltration via AI Inference APIAML.T0040AI Model Inference API AccessAML.T0042Verify AttackAML.T0057LLM Data LeakageCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
A SaaS provider runs a shared vLLM cluster behind an agent platform, using cache_salt to isolate customers. A malicious authenticated tenant knows that another customer's agent calls a tool that returns one of a few values (for example a risk tier or approval status), then continues the conversation. The attacker builds candidate continuation prefixes for each possible value, submits each to /v1/responses with tool continuation, and watches cached_tokens_per_turn. A large cached token count on one candidate shows that exact prefix was recently processed in the unsalted namespace, revealing the victim's tool result or conversation state. Repeating this over several turns lets the attacker reconstruct more of the victim's low-entropy context.
Weaknesses (CWE)
CWE-200Exposure of Sensitive Information to an Unauthorized ActorPrimaryCWE-200Exposure of Sensitive Information to an Unauthorized ActorPrimaryCWE-524Use of Cache Containing Sensitive InformationPrimaryCWE-524Use of Cache Containing Sensitive InformationPrimaryCWE-200Exposure of Sensitive Information to an Unauthorized ActorCWE-524Use of Cache Containing Sensitive InformationCWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
- [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.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:NReferences
- github.com/advisories/GHSA-935w-9g4m-p28p
- github.com/vllm-project/vllm/commit/6a2a2bb02b563b83f946012959fd3927984d072a
- github.com/vllm-project/vllm/pull/50195
- github.com/vllm-project/vllm/pull/51818
- github.com/vllm-project/vllm/releases/tag/v0.30.0
- github.com/vllm-project/vllm/security/advisories/GHSA-935w-9g4m-p28p
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm