CVE-2026-105752

vLLM: Harmony tool continuations drop cache_salt, restoring a cross-tenant prefix-cache membership oracle

# vllm/entrypoints/openai/responses/serving.py Lines 711-715
            if isinstance(context, HarmonyContext):
                token_ids = context.render_for_completion()
                engine_input = tokens_input(token_ids)

                sampling_params.max_tokens = max_model_len - len(token_ids)

# vllm/entrypoints/openai/responses/serving.py Lines 754-755
        prompt_token_ids = render_for_completion(messages)
        engine_input = tokens_input(prompt_token_ids, cache_salt=request.cache_salt)

# vllm/inputs/engine.py Lines 51-66
def tokens_input(
    prompt_token_ids: list[int],
    *,
    prompt: str | None = None,
    cache_salt: str | None = None,
) -> TokensInput:
    """
    Construct [`TokensInput`][vllm.inputs.engine.TokensInput]
    from optional values.
    """
    inputs = TokensInput(type="token", prompt_token_ids=prompt_token_ids)

    if prompt is not None:
        inputs["prompt"] = prompt
    if cache_salt is not None:
        inputs["cache_salt"] = cache_salt

An authenticated tenant of a shared deployment can recover whether a guessed post-tool prompt or history was processed by another tenant, with exact cached-token counts rather than noisy latency, the exact prompt-membership oracle cache_salt is documented to prevent. It defeats the multi-user prefix-cache isolation guarantee for salted Harmony tool sessions.

Preconditions: a GPT-OSS Harmony model on /v1/responses; prefix caching enabled (default); an operator-enabled built-in or MCP tool server; the victim sets cache_salt and triggers at least one tool continuation; and the attacker can reconstruct the post-tool history closely enough to match the token prefix. The AC:H metric reflects that guessable-history precondition.

CVE-2026-105752 has a CVSS score of 3.1 (Low). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.30.0); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

Propagate request.cache_salt into every Harmony (and Parsable) tool-continuation re-submission, at the continuation call site call tokens_input(token_ids, cache_salt=request.cache_salt), mirroring the correct turn-1 call. Carry the salt on the HarmonyContext (thread the originating request into the context) so no continuation path can omit it:

# vllm/entrypoints/openai/responses/serving.py
             if isinstance(context, HarmonyContext):
                 token_ids = context.render_for_completion()
-                engine_input = tokens_input(token_ids)
+                engine_input = tokens_input(
+                    token_ids,
+                    cache_salt=(
+                        context.request.cache_salt
+                        if context.request is not None
+                        else None
+                    ),
+                )

with HarmonyContext.__init__ gaining a request: ResponsesRequest | None = None parameter (stored as self.request) that _create_responses passes when constructing the context. The continuation prefix is then cached in the victim's salted namespace, mirroring turn 1.

Suggested regression test: assert cached_tokens_per_turn == 0 for a different-salt probe against a salted victim continuation (the four-way control from the proof of concept).

1. What is CVE-2026-105752? CVE-2026-105752 is a low-severity security vulnerability in vllm (pip), affecting versions < 0.30.0. It is fixed in 0.30.0.
2. How severe is CVE-2026-105752? CVE-2026-105752 has a CVSS score of 3.1 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of vllm are affected by CVE-2026-105752? vllm (pip) versions < 0.30.0 is affected.
4. Is there a fix for CVE-2026-105752? Yes. CVE-2026-105752 is fixed in 0.30.0. Upgrade to this version or later.
5. Is CVE-2026-105752 exploitable, and should I be worried? Whether CVE-2026-105752 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-105752 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-105752? Upgrade vllm to 0.30.0 or later.

Other vulnerabilities in vllm