3.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-105752

CVE-2026-105752: vLLM: Harmony tool continuations drop `cache_salt` — restoring a cross-tenant prefix-cache membership oracle

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.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-105752

CVE-2026-105752:

3.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

SSVC / BOD 26-04 ↗

Exploitation NoneAutomatable NoTech Impact Partial

Select your environment

→SSVCDeferfix on upgrade

Runtime reachability resolves your actual outcome.Book a demo

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
vllm	pip	< 0.30.0	0.30.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability, CVE-2026-105752, stems from a failure to propagate the cache_salt parameter during tool-continuation re-submissions in vLLM's Harmony API (/v1/responses). The cache_salt is crucial for multi-tenant isolation in the prefix cache. The core issue is that while the initial request correctly includes cache_salt, subsequent turns after a tool call (which are re-submitted internally) omit this parameter. This causes the continuation prefixes to be cached in a global, unsalted namespace, making them discoverable by other tenants.

The analysis of the provided commit 6a2a2bb02b563b83f946012959fd3927984d072a and the vulnerability description points to OpenAIServingResponses._create_responses in vllm/entrypoints/openai/responses/serving.py as the primary vulnerable function. This function was responsible for handling the multi-turn logic for Harmony requests. Specifically, within this function, when a HarmonyContext was active (indicating a tool-use scenario), the code would call tokens_input(token_ids) without passing the cache_salt for continuation turns. This omission led to the security bypass.

The patch addresses this by refactoring the prompt rendering logic. Instead of directly calling tokens_input(token_ids) without the salt, the updated code now uses a new OnlineRenderer.render_responses method, which is designed to correctly propagate the cache_salt throughout all turns of the conversation. Therefore, the _create_responses function, in its state prior to this patch, contained the vulnerable logic that failed to maintain the cache_salt for tool continuations, leading to the information leakage.

Vulnerable functions

OpenAIServingResponses._create_responses

vllm/entrypoints/openai/responses/serving.py

This function orchestrates the multi-turn request-response cycle for the Harmony tool-use path. In a vulnerable version, when a tool call occurs, this function re-submits the next turn's prompt to the engine. During this re-submission, it fails to include the original request's `cache_salt`. As a result, the prompt's prefix is stored in a global, unsalted cache. This allows another tenant on a shared system to probe the cache for the existence of specific prompts (by guessing the post-tool history), thereby breaking the multi-tenant isolation that `cache_salt` is designed to provide. The patch evidence shows that the `tokens_input` call within this function was missing the `cache_salt` parameter for continuation turns, leading to the vulnerability. The fix involves refactoring this logic to ensure `cache_salt` is always propagated, indicating that the original `_create_responses` function was the point of failure for salt propagation in tool continuations before the fix was applied. While the patch moves the logic, the *vulnerable behavior* was present in how `_create_responses` handled these continuations by implicitly calling `tokens_input` without the salt. Therefore, `_create_responses` is the vulnerable function that would be in the call stack during exploitation of this specific flaw in the vulnerable version of the code, as it's the entry point for processing these multi-turn requests where the salt is dropped for continuations. The specific lines mentioned in the advisory (712-713) are within the context of this function's execution flow for Harmony contexts. The patch effectively removes the vulnerable logic from this function and replaces it with a call to a new, corrected rendering mechanism, confirming `_create_responses` as the site of the vulnerability in the original code structure. The `OnlineRenderer.render_responses` is the *new* function that correctly handles the salt, but the *vulnerable* function was the one that *failed* to do so, which was `_create_responses` in the context of Harmony tool continuations. The patch evidence shows the removal of the direct `tokens_input(token_ids)` call and its replacement with a call to a new rendering mechanism that correctly propagates the salt, thus confirming `_create_responses` as the function containing the vulnerable logic in the original version. The vulnerability description itself points to `vllm/entrypoints/openai/responses/serving.py#L712-L713` as 'The drop (sink)', which is within the `_create_responses` function's execution path for Harmony contexts. The patch then modifies this exact section to correctly pass the `cache_salt`.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

3.1

-

Basic Information

Basic Information

Concerned about an active attack path?

CVE-2026-105752: vLLM: Harmony tool continuations drop `cache_salt` — restoring a cross-tenant prefix-cache membership oracle

CVE-2026-105752:

3.1

-

Basic Information

Basic Information

Is this CVE running in your environment?

Technical Details

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

Vulnerable functions

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

WAF Protection Rules

WAF Rule

Detect and Respond To Threats Faster.

3.1

3.1

Basic Information

Basic Information

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

Vulnerable functions

Technical Details

CVE-2026-105752: vLLM: Harmony tool continuations drop `cache_salt` — restoring a cross-tenant prefix-cache membership oracle

3.1

-

Basic Information

Basic Information

Concerned about an active attack path?

CVE-2026-105752: vLLM: Harmony tool continuations drop `cache_salt` — restoring a cross-tenant prefix-cache membership oracle

CVE-2026-105752:

3.1

-

Basic Information

Basic Information

Is this CVE running in your environment?

Technical Details

Technical Details

Vulnerability IntelligenceMiggo AI

Root Cause Analysis

Vulnerable functions

Vulnerability IntelligenceMiggo AI

Unlock WAF rules for this CVE

WAF Protection Rules

WAF Rule

3.1

3.1

Basic Information

Basic Information

Vulnerability IntelligenceMiggo AI

Root Cause Analysis

Vulnerable functions

Technical Details

CVE-2026-105752: vLLM: Harmony tool continuations drop `cache_salt` — restoring a cross-tenant prefix-cache membership oracle

Vulnerability Intelligence
Miggo AI

Vulnerability Intelligence
Miggo AI

Vulnerability Intelligence
Miggo AI