Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-53923

CVE-2026-53923: Vllm Information Disclosure Vulnerability

CVE-2026-53923 is an information disclosure vulnerability in Vllm that exposes GPU memory from other users' inference requests in multi-tenant deployments. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-53923 Overview

CVE-2026-53923 is an information disclosure vulnerability in vLLM, an inference and serving engine for large language models (LLMs). The flaw affects versions from 0.5.5 up to but not including 0.23.1rc0. Integer truncation of tensor dimensions in the GGUF dequantize CUDA kernels (csrc/quantization/gguf/gguf_kernel.cu) causes partial tensor processing. The output tensor is allocated at full size with torch::empty but only a truncated number of elements get written. Residual GPU memory from prior inference requests remains exposed in the unfilled region, enabling cross-tenant data leakage [CWE-200].

Critical Impact

In multi-tenant inference deployments, attackers submitting GGUF-quantized inference requests may receive residual GPU memory containing tensor data from other users' inference sessions.

Affected Products

  • vLLM versions 0.5.5 through 0.23.0
  • vLLM deployments using GGUF-quantized model formats
  • Multi-tenant LLM inference services built on vulnerable vLLM releases

Discovery Timeline

  • 2026-06-22 - CVE-2026-53923 published to NVD
  • 2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53923

Vulnerability Analysis

The vulnerability resides in vLLM's GGUF dequantization path. The output tensor DW is allocated using torch::stable::empty({m, n}, ...), which returns uninitialized GPU memory. The dequantize kernel then iterates over a counter declared with 32-bit signed integer width. When the total element count exceeds INT32_MAX, the loop terminates early and writes only a truncated subset of the tensor.

The remaining memory region keeps whatever data the GPU allocator previously held. On shared inference infrastructure, that memory frequently contains tensors, KV-cache fragments, or activations from prior tenants' requests. An attacker crafting an inference request large enough to trigger truncation can read that residual data when the partially-initialized tensor is returned.

Root Cause

The root cause is a numeric truncation error in the kernel dispatch signature. The function pointer type to_cuda_ggml_t declared the element count k as int, forcing implicit truncation of 64-bit tensor sizes passed from PyTorch. Large GGUF tensors silently wrapped or truncated, causing the kernel to process fewer elements than allocated.

Attack Vector

Exploitation requires the ability to submit GGUF-quantized inference requests to a shared vLLM endpoint. No authentication bypass is needed when the service exposes inference APIs to untrusted users. The attacker submits a request sized to trigger truncation, then inspects the returned tensor for residual GPU memory contents.

c
// Patch: widen element count from int to int64_t to prevent truncation
 typedef half2 dfloat2;
 typedef void (*dequantize_kernel_t)(const void * vx, const int ib, const int iqs, dfloat2 & v);
 template<typename dst_t>
-using to_cuda_ggml_t = void (*)(const void * __restrict__ x, dst_t * __restrict__ y, int k, cudaStream_t stream);
+using to_cuda_ggml_t = void (*)(const void * __restrict__ x, dst_t * __restrict__ y, int64_t k, cudaStream_t stream);

Source: vLLM commit f219788

Detection Methods for CVE-2026-53923

Indicators of Compromise

  • Inference responses containing unexpected token sequences, embeddings, or tensor values not derivable from the submitted prompt.
  • vLLM server logs showing GGUF dequantization calls with tensor dimensions exceeding INT32_MAX element counts.
  • Anomalous request patterns submitting oversized GGUF-quantized payloads to inference endpoints.

Detection Strategies

  • Inventory all vLLM deployments and identify instances running versions 0.5.5 through 0.23.0 with GGUF model support enabled.
  • Inspect inference output statistics for distributions inconsistent with expected model behavior, which may indicate uninitialized memory in returned tensors.
  • Audit API access logs for repeated large-tensor GGUF requests from a single client, particularly in multi-tenant environments.

Monitoring Recommendations

  • Enable request and response logging on vLLM API endpoints and forward to a centralized analytics platform for anomaly review.
  • Monitor GPU memory allocation patterns and tensor sizes processed by the GGUF kernel path.
  • Alert on inference requests whose tensor dimensions approach or exceed 32-bit integer boundaries.

How to Mitigate CVE-2026-53923

Immediate Actions Required

  • Upgrade vLLM to version 0.23.1rc0 or later, which contains the official fix.
  • Restrict GGUF model loading on multi-tenant inference services until patching is complete.
  • Apply tenant isolation by running separate vLLM processes per customer where shared infrastructure cannot be patched immediately.

Patch Information

The fix is delivered in vLLM 0.23.1rc0 via commit f219788f91952827132fa4fdf916427cd20d225e. The patch widens the kernel element count from int to int64_t and explicitly zero-initializes the output tensor with torch::stable::fill_(DW, 0.0) before kernel execution. Review the vLLM Security Advisory GHSA-5jv2-g5wq-cmr4 and the vLLM Pull Request #44971 for full details.

text
   auto DW = torch::stable::empty({m, n}, dtype_, std::nullopt, W.device());
+  torch::stable::fill_(DW, 0.0);
   cudaStream_t stream = get_current_cuda_stream();

Source: vLLM commit f219788

Workarounds

  • Disable GGUF quantization support in vLLM until the patch is applied.
  • Limit inference request sizes at the API gateway to prevent tensors large enough to trigger 32-bit truncation.
  • Dedicate GPU resources per tenant so residual memory cannot contain another user's data.
bash
# Upgrade to the patched vLLM release
pip install --upgrade "vllm>=0.23.1rc0"

# Verify the installed version
python -c "import vllm; print(vllm.__version__)"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.