CVE-2026-53923: vLLM GPU Memory Information Disclosure in GGUF Dequantize Kernels

Technical summary

The GGUF dequantize kernel (csrc/quantization/gguf/gguf_kernel.cu) in vLLM performs integer truncation of tensor dimensions during GPU computation. The kernel allocates output tensors at full size via torch::empty(), which returns uninitialized GPU memory, but the CUDA kernel only processes a truncated element count. This mismatch leaves a portion of each output tensor unwritten. In multi-tenant environments where GPU resources are pooled across different users or requests, the residual GPU memory in the unfilled portion may contain tensor data from prior inference operations, enabling one tenant to read another's data through subsequent inference requests that reuse that GPU memory.

Business impact

For cloud LLM service providers and enterprises running shared vLLM inference clusters, this vulnerability creates a cross-tenant data exposure risk. Customer prompts, model outputs, embeddings, or intermediate activation values from one user's inference could be leaked to another user. This is particularly critical for deployments handling sensitive data (healthcare, finance, legal queries). The exposure is indirect—an attacker must trigger inference requests that reuse the GPU memory—but requires no authentication or special privileges. Incident response may include notifying affected customers, auditing query logs to determine what data may have been at risk, and potentially replaying inference to determine exposure scope.

Affected systems

vLLM versions 0.5.5 through 0.23.0 (inclusive) are vulnerable. The issue is resolved in 0.23.1rc0 and later stable releases. Any deployment using GGUF-quantized model formats on NVIDIA GPUs with shared multi-user inference is at risk; single-user or non-GGUF deployments are unaffected. The vulnerability is in the GPU kernel code path and requires CUDA support.

Exploitability

Exploitability is practical but not immediate. An attacker cannot trigger a vulnerability directly; rather, they must cause the inference server to allocate and process GGUF tensors such that uninitialized GPU memory persists in the output, then retrieve that output as part of a subsequent inference request. This requires either: (1) direct API access to the inference service, or (2) ability to craft or submit inference requests as a legitimate (but untrusted) user. No patch or authentication bypass is required—the vulnerability surfaces through normal inference operations. The CVSS score of 7.5 reflects high confidentiality impact with network accessibility and no authentication requirement, though practical exploitation depends on multi-tenant deployment patterns.

Remediation

Update vLLM to version 0.23.1rc0 or later. Administrators should prioritize this patch for any cloud or shared-inference deployments. A temporary mitigation for urgent environments might include isolating inference workloads per user (separate processes or containers) to prevent GPU memory reuse across tenants, though this reduces efficiency and is not a permanent substitute for patching.

Patch guidance

Verify the current vLLM version in your deployment (e.g., via pip show vllm or python -c "import vllm; print(vllm.__version__)"). If running any version from 0.5.5 to 0.23.0, proceed with an immediate upgrade to 0.23.1rc0 or a later stable release. The vLLM project typically publishes releases on PyPI and GitHub; follow your organization's standard patching process for dependency updates, including testing in a staging environment. Coordinate with teams running on-premise or cloud instances to ensure consistent updates across all inference clusters.

Detection guidance

Intrusion detection is limited because the vulnerability exploits normal API operations. Focus instead on: (1) inventory—enumerate all vLLM deployments and their versions via asset management or API queries; (2) configuration audit—identify multi-tenant or shared-inference clusters where memory reuse is likely; (3) logging—if your inference service logs request/response metadata, review logs around the same timeframe for requests from different users or API keys to detect potential temporal reuse patterns (difficult in practice without specialized instrumentation); (4) forward-looking—after patching, consider adding GPU memory initialization flags or periodic zeroing as a defense-in-depth measure, though the patch itself should be sufficient.

Why prioritize this

This is a HIGH-severity cross-tenant information disclosure affecting production inference engines. For any organization running shared vLLM infrastructure, it should be treated as urgent because: (1) the confidentiality impact is direct and touches user data; (2) no special configuration or authentication bypass is needed; (3) multi-tenant cloud deployments are increasingly common in LLM inference; (4) the affected version range has been in use for extended periods. However, it is not critical (CVSS not 9+) because exploitation requires shared GPU resources and is not a remote code execution or denial-of-service vector. Patch within days for shared deployments, and within one to two weeks for single-user or research environments.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects: Attack Vector: Network (the inference API is accessible over the network); Attack Complexity: Low (no special conditions required); Privileges Required: None (any user with API access can trigger inference); User Interaction: None (fully automated); Scope: Unchanged (no boundary violation); Confidentiality: High (previous user data is exposed); Integrity: None (data is not modified); Availability: None (no service disruption). The score appropriately captures the severity of information disclosure in a multi-tenant environment without overstating it as a system-level compromise.

Frequently asked questions