AI Threat AlertCVE-2026-126395: vLLM: heap address leak via error message redaction
MEDIUMvLLM versions 0.14.0rc1 up to (but not including) 0.31.0 fail to fully scrub memory addresses from error messages because the sanitize_message() regex only matches lowercase hex, so uppercase PIL image addresses survive and are returned to unauthenticated callers of endpoints such as /tokenize. On its own this is a medium-severity (CVSS 5.3) information leak with no direct confidentiality or integrity impact, no public exploit, no Nuclei template, and no CISA KEV listing, and EPSS data is not yet available. The real concern is chaining: leaked live heap addresses help defeat ASLR and could make a separate memory-corruption or code-execution bug in the inference stack far more reliable to exploit. Upgrade to vLLM 0.31.0 or later, and in the meantime avoid exposing vLLM API endpoints directly to untrusted networks and place them behind an authenticating gateway.
What is the risk?
Overall risk is low to medium. Exploitation is trivial (network-reachable, no authentication, no user interaction, low complexity) but the direct impact is limited to low-level confidentiality loss of process memory addresses. There is no known public exploit, no scanner template, and no KEV listing, and EPSS is not available, so near-term mass exploitation is unlikely. Risk rises for internet-exposed vLLM servers that run without an API key or gateway, especially multimodal deployments that accept image input, and for environments where other memory-safety flaws exist in the inference stack that an attacker could pair with the ASLR bypass.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vLLM to 0.31.0 or later, which fixes the case-insensitive address scrubbing in sanitize_message(). 2) Until patched, require authentication (API key, mTLS, or an authenticating reverse proxy) for all vLLM endpoints and do not expose them to the internet. 3) Restrict network access to the inference service with segmentation and allow-lists. 4) At the gateway, normalize or replace upstream error bodies so that raw exception text and memory addresses are never returned to clients. 5) Detect by alerting on repeated 4xx/5xx responses from /tokenize and multimodal endpoints with malformed image payloads, and by searching response logs for hex address patterns such as 0x7f... in error bodies. 6) Review the GHSA-m9fg-w9qh-67pc advisory and keep other vLLM components up to date to limit the value of any address leak.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-126395?
vLLM versions 0.14.0rc1 up to (but not including) 0.31.0 fail to fully scrub memory addresses from error messages because the sanitize_message() regex only matches lowercase hex, so uppercase PIL image addresses survive and are returned to unauthenticated callers of endpoints such as /tokenize. On its own this is a medium-severity (CVSS 5.3) information leak with no direct confidentiality or integrity impact, no public exploit, no Nuclei template, and no CISA KEV listing, and EPSS data is not yet available. The real concern is chaining: leaked live heap addresses help defeat ASLR and could make a separate memory-corruption or code-execution bug in the inference stack far more reliable to exploit. Upgrade to vLLM 0.31.0 or later, and in the meantime avoid exposing vLLM API endpoints directly to untrusted networks and place them behind an authenticating gateway.
Is CVE-2026-126395 actively exploited?
No confirmed active exploitation of CVE-2026-126395 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-126395?
1) Upgrade vLLM to 0.31.0 or later, which fixes the case-insensitive address scrubbing in sanitize_message(). 2) Until patched, require authentication (API key, mTLS, or an authenticating reverse proxy) for all vLLM endpoints and do not expose them to the internet. 3) Restrict network access to the inference service with segmentation and allow-lists. 4) At the gateway, normalize or replace upstream error bodies so that raw exception text and memory addresses are never returned to clients. 5) Detect by alerting on repeated 4xx/5xx responses from /tokenize and multimodal endpoints with malformed image payloads, and by searching response logs for hex address patterns such as 0x7f... in error bodies. 6) Review the GHSA-m9fg-w9qh-67pc advisory and keep other vLLM components up to date to limit the value of any address leak.
What systems are affected by CVE-2026-126395?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, multimodal inference pipelines, OpenAI-compatible API gateways.
What is the CVSS score for CVE-2026-126395?
CVE-2026-126395 has a CVSS v3.1 base score of 5.3 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0006Active ScanningAML.T0040AI Model Inference API AccessAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM from 0.14.0rc1 before 0.31.0 contains an information disclosure vulnerability in sanitize_message() whose lowercase-only regex fails to scrub uppercase PIL image addresses. Unauthenticated attackers can send a crafted PNG to endpoints such as /tokenize, triggering HF-processor errors that leak live server heap addresses useful for ASLR bypass.
Exploitation Scenario
An attacker finds an internet-reachable vLLM server running a multimodal model with no authentication in front of it. They send a crafted PNG to /tokenize that causes the Hugging Face image processor to raise an exception referencing a PIL image object. Because the redaction regex only handles lowercase hex, the uppercase address passes through, and the error response returns a live heap address. The attacker repeats the request to learn the memory layout and uses it as an ASLR bypass to make a separate memory-corruption exploit against the inference process reliable.
Weaknesses (CWE)
CWE-532Insertion of Sensitive Information into Log FilePrimaryCWE-532Insertion of Sensitive Information into Log FileCWE-532 — Insertion of Sensitive Information into Log File: The product writes sensitive information to a log file.
- [Architecture and Design, Implementation] Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
- [Distribution] Remove debug log files before deploying the application into production.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm