vLLM drops cache salt in tool turns, leaking prompt hints

A security advisory published on 6 October 2026 says vLLM, the open-source large language model serving engine, silently drops the cache_salt parameter when it continues a request after a tool call. The advisory, tracked as GHSA-935w-9g4m-p28p and CVE-2026-105752, says all versions up to and including 0.25.1 are affected, confirmed on 0.25.1. The lower bound of the affected range is not established; the advisory says maintainers can confirm how far back the behaviour goes. The status is reported, with no fixed version named in the advisory.

The problem sits on the GPT-OSS "Harmony" path, reached through the POST /v1/responses endpoint. According to the advisory, a request that uses a built-in or MCP tool runs as a multi-turn loop: after each tool call, vLLM rebuilds the full next-turn prompt and re-submits it to the engine. The first turn correctly carries the caller's cache_salt, a value that is meant to keep one tenant's cached prompt prefixes in a separate namespace from everyone else's. The continuation turns rebuild the engine input without it, so those prefixes land in the shared, unsalted cache.

The advisory describes the consequence as a prompt-membership oracle, meaning a way to test whether a particular prompt has been processed before. An authenticated tenant on a shared deployment who can guess a low-entropy post-tool history can submit the reconstructed continuation and read exact per-turn cached-token counts from the Responses API usage field, cached_tokens_per_turn. That gives exact counts rather than noisy timing measurements. The advisory says this defeats the multi-user prefix-cache isolation guarantee for salted Harmony tool sessions, and calls the behaviour a broken isolation control, because the caller opted into salting and every turn should have stayed isolated.

The advisory distinguishes the issue from GHSA-4qjh-9fv9-r85r (CVE-2025-46570), the earlier prefix-cache membership oracle for which cache_salt is the documented mitigation. It says the earlier fix, PR-17045, does not close this code path, because the leak comes from a different sink: the Responses serving continuation rather than general time-to-first-token timing.

The advisory pins the relevant code to commit 752a3a504485 of version 0.25.1. It points to the continuation call that builds the engine input with no salt, and contrasts it with the first-turn call that passes request.cache_salt. Helper code stores the salt on the engine input only when it is passed, the engine request copies only the current input's salt, and the prefix-cache hashing keys on the salt only when it is present. Preconditions listed include a GPT-OSS Harmony model served on /v1/responses and prefix caching enabled.

A second advisory for vLLM, GHSA-ph3r-5jfg-f84f (CVE-2026-105753), was published the same day and covers the same affected range. It describes a desync between vLLM's mirrored multimodal caches, split across the frontend process and the engine core. If a request is rejected after the frontend has rendered and hashed media but before the engine core receives it, the two caches disagree. A later request reusing the same media hash then trips an assertion in the engine core. The advisory says this affects the default cache configuration, mm_processor_cache_type="lru", and that the processor_only, disabled-caching and shm paths are not affected.