CVE-2026-22778

vLLM leaks a heap address when PIL throws an error

Exploitation likely. EPSS gives it a 17% chance of exploitation in the next 30 days. Fixed in 0.14.1.

CVSS 3.19.8Critical EPSS percentile97th17% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known Fix0.14.1Upgrade to this build

Published 2026-02-02Updated 2026-07-15Sources: CVE.org, NVD, GitHub

NVD CVE.org

What to do

Find your product and version, then upgrade to the build on the right.

Vllm-project VllmAffected: >= 0.8.3, < 0.14.1Upgrade to: not statedStated by: CVE record
PyPI vllmAffected: ≥ 0.8.3, < 0.14.1Upgrade to: 0.14.1Stated by: GitHub advisory

Versions as the sources state them. Full version matrix after sign-in

Steps

Written by AI from the record

Check if you are running vLLM between version 0.8.3 and 0.14.0, especially with image/multimodal features enabled.
Confirm whether the vLLM API endpoint is reachable from the internet or untrusted networks.
Upgrade vLLM to version 0.14.1 or later.
If you cannot upgrade immediately, restrict access to the multimodal/image endpoint to trusted internal networks only.
After upgrading, verify error responses no longer include memory address details when sending test malformed images.

Vendor advisory Usually a quick update

Check it yourselfA free Nuclei check exists for this CVE. Run it against your hosts.Is your organisation exposed?Discuss checks for your systems with a specialist. Scope is agreed before testing.

What it is

From the CVE record

vLLM is an inference and serving engine for large language models (LLMs). From 0.8.3 to before 0.14.1, when an invalid image is sent to vLLM's multimodal endpoint, PIL throws an error. vLLM returns this error to the client, leaking a heap address. With this leak, we reduce ASLR from 4 billion guesses to ~8 guesses. This vulnerability can be chained a heap overflow with JPEG2000 decoder in OpenCV/FFmpeg to achieve remote code execution. This vulnerability is fixed in 0.14.1.

In plain language

Written by AI from the record

If you run vLLM (versions 0.8.3 to 0.14.0) to serve AI models that accept images, a bad actor can trick it into leaking a hidden server memory address just by sending a broken image — this is a stepping stone toward a full server takeover, so you should update to 0.14.1 or later soon.

Unauthenticated information disclosure in vLLM's multimodal endpoint — malformed images trigger a PIL error that reflects a heap address to the client, defeating ASLR and enabling chaining with a separate JPEG2000 decoder heap overflow for remote code execution.

If you're affected

Full server takeover risk
AI service downtime
Stepping stone to remote code execution
Exposure of internal model infrastructure

What is it

Think of this like a burglar sending a fake delivery package to your office, and when staff reject it, they accidentally read out the office safe's combination over the intercom. Here, sending a broken image file to the AI server causes it to reply with a secret internal memory address instead of just an error. That address alone isn't a break-in, but it hands an attacker the key piece of information needed to pull off a bigger attack, including fully hijacking the server.

Who is affected

This matters to you if you run vLLM (versions 0.8.3 through 0.14.0) to serve AI models, particularly any setup that accepts image uploads through its multimodal API. It's a risk if that API endpoint is reachable from the internet or any untrusted network — no login or user action is needed for an attacker to exploit it.

How urgent is it

There is no confirmed active exploitation yet, and this flaw by itself only leaks information rather than directly breaking in — but it's a known building block that significantly lowers the bar for a more serious remote takeover when combined with other bugs. Given it requires no authentication and is reachable by default, you should plan to patch promptly rather than treat this as low priority.

What to do — in detail

Identify all vLLM deployments and check their version — affected range is 0.8.3 up to (but not including) 0.14.1.
Determine whether the multimodal/image endpoint is exposed to untrusted networks (internet-facing or shared internal network without access controls).
Upgrade to vLLM >= 0.14.1, which fixes the error handling so PIL exceptions no longer leak heap addresses (see PRs #31987 and #32319, and advisory GHSA-4r2x-xpjr-7cvv).
If immediate upgrade isn't possible, place the vLLM API behind an authenticating reverse proxy or restrict network access to the multimodal endpoint, and consider disabling multimodal/image input temporarily.
After patching, test by submitting a deliberately malformed image and confirm the error response no longer contains memory addresses or other internal details.
Monitor for follow-on exploitation attempts, particularly any requests probing image decoding paths (e.g., JPEG2000) that could indicate chaining toward the heap overflow RCE path mentioned in the advisory.

Technical context

CVSS 9.8 (Critical), AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — unauthenticated, network-reachable, no user interaction, high impact to confidentiality/integrity/availability. Weakness: CWE-532 (information exposure through log/error message) and CWE-209 (error message containing sensitive information). The flaw leaks a heap address via PIL exception handling on the multimodal endpoint, reducing ASLR entropy from ~4 billion to ~8 possible guesses, which the advisory notes can be chained with a known heap overflow in JPEG2000 decoding (OpenCV/FFmpeg) to achieve remote code execution. Not currently in CISA KEV; no confirmed in-the-wild exploitation. A detection template exists but no public weaponized exploit. EPSS predicts a rising likelihood of exploitation activity (currently in a high percentile relative to all CVEs), reflecting elevated attacker interest given the critical severity and network reachability. Fixed in vllm 0.14.1.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS97th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

17% chance of exploitation activity in the next 30 days, which ranks it in the 97th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

10 events over 240 days, from the signal feeds we watch.

2026-09-30EPSS band changelow → moderateepss band change
2026-07-15Patch availablerecord updated
2026-06-29Patch availablerecord updated
2026-06-28Nuclei check added
2026-02-02Publishedweakness classified, att&ck mapped

Affected products

vllm-projectoss-projectaka vllm, vllm-project/vllm
- vllmMixedAI / ML / llm-serving-inference
PyPIpackage-ecosystem
- vllmOSS Libraries
vllmoss-projectaka aibrix
- vllmMixedAI / ML / llm-serving-inference

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Scored 9.8 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required NoneNo authentication required — anyone can exploit this
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability HighTotal denial of service — the component is completely unavailable