CVE-2026-105752

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.

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.

Affected

• Ecosystem / package: pip / vllm
• Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the tool-continuation re-submission has omitted the salt.

Summary

On the GPT-OSS "Harmony" path (POST /v1/responses), a request that uses a built-in or MCP tool runs as a multi-turn loop: after each tool call vLLM re-renders the full next-turn Harmony prompt and re-submits it to the engine. Turn 1 correctly carries request.cache_salt, but the tool-continuation re-submission rebuilds the engine input via tokens_input(token_ids) with no cache_salt. The continuation prefix is therefore cached in the global unsalted namespace even though the caller opted into salting. A second tenant who can guess the low-entropy post-tool history submits the reconstructed continuation (unsalted) and reads exact per-turn cached-token counts from the Responses usage — restoring the prompt-membership oracle that cache_salt is documented to prevent.

Silently dropping a preserved salt after the supported tool workflow is enabled is a broken isolation control: the caller enabled salting and every turn should stay isolated, but continuation turns leak into the shared cache.

This is distinct from GHSA-4qjh-9fv9-r85r (CVE-2025-46570): that advisory is the prefix-cache membership oracle for which cache_salt is the documented mitigation, and its PR-17045 fix does not close this site — the Harmony tool continuation silently drops the preserved salt, caching in the unsalted namespace and leaking exact cached_tokens_per_turn counts from a different sink (the Responses serving continuation, not general TTFT timing).

Affected code

Links pinned to the confirmed commit 752a3a504485 (v0.25.1):

• The drop (sink): vllm/entrypoints/openai/responses/serving.py#L712-L713 — token_ids = context.render_for_completion() then engine_input = tokens_input(token_ids), with no cache_salt.
• Correct turn-1 call for contrast: vllm/entrypoints/openai/responses/serving.py#L755 — tokens_input(prompt_token_ids, cache_salt=request.cache_salt).
• tokens_input stores the salt only if passed: vllm/inputs/engine.py#L51-L66 (if cache_salt is not None: inputs["cache_salt"] = cache_salt).
• The engine request copies only the current input's salt: vllm/v1/engine/input_processor.py#L380 (cache_salt=decoder_inputs.get("cache_salt") → None for the continuation).
• Prefix-cache hashing keys on the salt only when present: vllm/v1/core/kv_cache_utils.py#L560-L561 ([request.cache_salt] if (start_token_idx == 0 and request.cache_salt) else []).
• The oracle the attacker reads: vllm/entrypoints/openai/responses/serving.py#L909 (cached_tokens_per_turn).
• The documented control being defeated:…

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.

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.

Affected

• Ecosystem / package: pip / vllm
• Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the tool-continuation re-submission has omitted the salt.

Summary

On the GPT-OSS "Harmony" path (POST /v1/responses), a request that uses a built-in or MCP tool runs as a multi-turn loop: after each tool call vLLM re-renders the full next-turn Harmony prompt and re-submits it to the engine. Turn 1 correctly carries request.cache_salt, but the tool-continuation re-submission rebuilds the engine input via tokens_input(token_ids) with no cache_salt. The continuation prefix is therefore cached in the global unsalted namespace even though the caller opted into salting. A second tenant who can guess the low-entropy post-tool history submits the reconstructed continuation (unsalted) and reads exact per-turn cached-token counts from the Responses usage — restoring the prompt-membership oracle that cache_salt is documented to prevent.

Silently dropping a preserved salt after the supported tool workflow is enabled is a broken isolation control: the caller enabled salting and every turn should stay isolated, but continuation turns leak into the shared cache.

This is distinct from GHSA-4qjh-9fv9-r85r (CVE-2025-46570): that advisory is the prefix-cache membership oracle for which cache_salt is the documented mitigation, and its PR-17045 fix does not close this site — the Harmony tool continuation silently drops the preserved salt, caching in the unsalted namespace and leaking exact cached_tokens_per_turn counts from a different sink (the Responses serving continuation, not general TTFT timing).

Affected code

Links pinned to the confirmed commit 752a3a504485 (v0.25.1):

• The drop (sink): vllm/entrypoints/openai/responses/serving.py#L712-L713 — token_ids = context.render_for_completion() then engine_input = tokens_input(token_ids), with no cache_salt.
• Correct turn-1 call for contrast: vllm/entrypoints/openai/responses/serving.py#L755 — tokens_input(prompt_token_ids, cache_salt=request.cache_salt).
• tokens_input stores the salt only if passed: vllm/inputs/engine.py#L51-L66 (if cache_salt is not None: inputs["cache_salt"] = cache_salt).
• The engine request copies only the current input's salt: vllm/v1/engine/input_processor.py#L380 (cache_salt=decoder_inputs.get("cache_salt") → None for the continuation).
• Prefix-cache hashing keys on the salt only when present: vllm/v1/core/kv_cache_utils.py#L560-L561 ([request.cache_salt] if (start_token_idx == 0 and request.cache_salt) else []).
• The oracle the attacker reads: vllm/entrypoints/openai/responses/serving.py#L909 (cached_tokens_per_turn).
• The documented control being defeated:…

Affected

• Ecosystem / package: pip / vllm
• Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back the tool-continuation re-submission has omitted the salt.

Summary

On the GPT-OSS "Harmony" path (POST /v1/responses), a request that uses a built-in or MCP tool runs as a multi-turn loop: after each tool call vLLM re-renders the full next-turn Harmony prompt and re-submits it to the engine. Turn 1 correctly carries request.cache_salt, but the tool-continuation re-submission rebuilds the engine input via tokens_input(token_ids) with no cache_salt. The continuation prefix is therefore cached in the global unsalted namespace even though the caller opted into salting. A second tenant who can guess the low-entropy post-tool history submits the reconstructed continuation (unsalted) and reads exact per-turn cached-token counts from the Responses usage — restoring the prompt-membership oracle that cache_salt is documented to prevent.

Silently dropping a preserved salt after the supported tool workflow is enabled is a broken isolation control: the caller enabled salting and every turn should stay isolated, but continuation turns leak into the shared cache.

This is distinct from GHSA-4qjh-9fv9-r85r (CVE-2025-46570): that advisory is the prefix-cache membership oracle for which cache_salt is the documented mitigation, and its PR-17045 fix does not close this site — the Harmony tool continuation silently drops the preserved salt, caching in the unsalted namespace and leaking exact cached_tokens_per_turn counts from a different sink (the Responses serving continuation, not general TTFT timing).

Affected code

Links pinned to the confirmed commit 752a3a504485 (v0.25.1):

• The drop (sink): vllm/entrypoints/openai/responses/serving.py#L712-L713 — token_ids = context.render_for_completion() then engine_input = tokens_input(token_ids), with no cache_salt.
• Correct turn-1 call for contrast: vllm/entrypoints/openai/responses/serving.py#L755 — tokens_input(prompt_token_ids, cache_salt=request.cache_salt).
• tokens_input stores the salt only if passed: vllm/inputs/engine.py#L51-L66 (if cache_salt is not None: inputs["cache_salt"] = cache_salt).
• The engine request copies only the current input's salt: vllm/v1/engine/input_processor.py#L380 (cache_salt=decoder_inputs.get("cache_salt") → None for the continuation).
• Prefix-cache hashing keys on the salt only when present: vllm/v1/core/kv_cache_utils.py#L560-L561 ([request.cache_salt] if (start_token_idx == 0 and request.cache_salt) else []).
• The oracle the attacker reads: vllm/entrypoints/openai/responses/serving.py#L909 (cached_tokens_per_turn).
• The documented control being defeated:…