CVE-2026-105752: vLLM Prefix Cache Information Disclosure

CVE-2026-105752 Overview

CVE-2026-105752 affects vLLM, an inference and serving engine for large language models. Prior to version 0.30.0, Harmony tool continuations submitted through POST /v1/responses requests rebuild the next-turn engine input without preserving the cache_salt value. This places the continuation prefix in the global unsalted cache namespace even when the caller enabled salting. On deployments with prefix caching enabled (the default), an authenticated tenant who can reconstruct a victim's low-entropy post-tool history can defeat the intended tenant isolation of salted prefix caching. The issue is classified as information exposure [CWE-200] and is fixed in version 0.30.0.

Critical Impact
Authenticated tenants can bypass salted prefix cache isolation and infer whether specific tool-continuation prefixes were previously processed by other tenants.

Affected Products

vLLM versions prior to 0.30.0
Deployments exposing the POST /v1/responses Harmony tool continuation endpoint
Multi-tenant vLLM deployments with prefix caching enabled (default configuration)

Discovery Timeline

2026-10-05 - CVE-2026-105752 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-105752

Vulnerability Analysis

The vulnerability resides in how vLLM handles Harmony tool continuation requests sent to the POST /v1/responses endpoint. When a continuation request arrives, the server rebuilds the next-turn engine input to process the follow-up turn. During this rebuild, the cache_salt value that the original caller supplied is not propagated into the reconstructed input. As a result, the continuation prefix is routed to the global unsalted prefix cache namespace rather than the tenant-scoped salted namespace.

Prefix caching accelerates inference by reusing prior KV cache state when it encounters a matching token prefix. The cached_tokens_per_turn counter returned to clients reflects how many tokens hit this cache. An authenticated tenant who can approximate another tenant's post-tool history can resubmit candidate continuations and observe the counter to confirm whether that prefix was already processed by another tenant.

Root Cause

The root cause is the omission of the cache_salt field when the Harmony tool continuation path reconstructs engine input for the subsequent turn. Salting is designed to partition the prefix cache per tenant, but the missing propagation causes the salted prefix check to fall back to the shared namespace. This is an information disclosure flaw [CWE-200] via a timing and cache-hit oracle rather than a direct data leak.

Attack Vector

Exploitation requires an authenticated tenant on a shared vLLM deployment with prefix caching enabled. The attacker must reconstruct or guess a low-entropy post-tool history for a victim, submit it as a Harmony tool continuation through POST /v1/responses, and inspect the cached_tokens_per_turn value in the response. A non-zero or elevated value indicates the prefix was previously processed, allowing the attacker to confirm sensitive tool interactions despite the victim enabling cache_salt.

python

# Patch excerpt: vllm/entrypoints/launchers/api_server/app_state.py
# Source: https://github.com/vllm-project/vllm/commit/6a2a2bb02b563b83f946012959fd3927984d072a

from vllm.engine.protocol import EngineClient
from vllm.entrypoints.chat_utils import load_chat_template
from vllm.entrypoints.launchers.cli_args import resolve_default_chat_template_kwargs
from vllm.entrypoints.mcp.tool_server import init_tool_server
from vllm.entrypoints.openai.models.protocol import BaseModelPath
from vllm.entrypoints.openai.models.serving import OpenAIServingModels
from vllm.entrypoints.serve.tokenize.serving import ServingTokenization

Source: GitHub Commit 6a2a2bb. The patch adds a stateless /v1/responses/render endpoint and preserves cache_salt across Harmony tool continuations.

Detection Methods for CVE-2026-105752

Indicators of Compromise

Repeated POST /v1/responses requests from a single authenticated principal that iterate over similar continuation payloads.
Response bodies showing variable cached_tokens_per_turn values across structurally similar requests from different tenants.
Elevated request volume targeting Harmony tool continuation flows without corresponding net-new generation activity.

Detection Strategies

Instrument the vLLM frontend to log the presence or absence of cache_salt on each POST /v1/responses turn and alert when continuations drop the salt.
Correlate cached_tokens_per_turn metrics with tenant identity to flag improbable cross-tenant cache hits.
Baseline per-tenant continuation patterns and detect enumeration-style probing of candidate tool histories.

Monitoring Recommendations

Forward vLLM access logs, request bodies (where policy permits), and prefix-cache metrics to a centralized analytics platform.
Monitor the /v1/responses endpoint for high-cardinality continuation payloads from the same API key.
Track upgrade status of all vLLM nodes to ensure version 0.30.0 or later is deployed everywhere.

How to Mitigate CVE-2026-105752

Immediate Actions Required

Upgrade vLLM to version 0.30.0 or later, which preserves cache_salt across Harmony tool continuations.
Audit multi-tenant deployments to confirm which API keys have access to POST /v1/responses and apply least privilege.
Rotate any cache_salt values that may have been relied upon for isolation prior to the upgrade.

Patch Information

The fix is included in vLLM 0.30.0. See the GitHub Release v0.30.0, the GitHub Security Advisory GHSA-935w-9g4m-p28p, and pull requests #50195 and #51818 for complete remediation details.

Workarounds

Disable prefix caching on multi-tenant deployments until the upgrade is complete.
Restrict the POST /v1/responses endpoint to trusted single-tenant workloads via network policy or API gateway rules.
Enforce stronger entropy in tool outputs and histories so victim prefixes cannot be feasibly reconstructed by other tenants.

bash

# Verify installed vLLM version and upgrade
pip show vllm | grep -i version
pip install --upgrade "vllm>=0.30.0"

# Optional: disable prefix caching as a temporary mitigation
vllm serve <model> --no-enable-prefix-caching