Vulnerability · CVE-2026-115914
vLLM DeepSeek-OCR image processing vulnerable to denial of service
Published Oct 26, 2026 · catalog updated Oct 28, 2026 · Red Hat Red Hat Enterprise Linux
Last checked Nov 4, 2026. A connected source was read within the last 7 days.
Check if you run it
No confirmed exploitation is on record for CVE-2026-115914. EPSS is 0.40%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.
Gaps on this record
- No vendor fix or required action is stored. Compare the linked advisory before you change production.
Same product and reporting
- CVE-2026-119776 · High
- CVE-2026-100302 · Medium
- CVE-2026-115448 · High
- CVE-2026-100252 · High
- CVE-2026-100235 · Medium
- Severity
- Medium6.5
- Known exploitation
- Not in CISA/VulnCheck KEV
- EPSS
- 0.40%
- Remediation
- Version ranges on file
- Affected products
- pip vllm · pypi vllm
## Summary Any vLLM deployment serving a model of the DeepSeek-OCR family — , , or (whose subclasses ) — can be **killed by a single unauthenticated chat request carrying an ordinary, schema-valid PNG image**, under completely default server configuration. The image model's input validation contains a guard inherited from the upstream DeepSeek-OCR reference implementation: In the original research code this was an empty-batch shortcut; in vLLM's serving architecture is the actual client image tensor, and the condition is **exactly satisfiable by a legitimate image**: the in-tree normalizes pixels with ( ), mapping pixel value 0 → exactly −1.0 and 255 → exactly +1.0 in float32. A 1024×1024 image that is half pure black and half pure white (a perfectly ordinary 1-bit-style scanned-document PNG for an OCR model) therefore yields **exactly** (equal counts of ±1.0; pairwise reduction stays integer-exact, well inside float32's 2²⁴ exactness bound). is the identity map for an already-1024×1024 image ( ), so no padding pixels disturb the balance. Returning makes return ( ), which immediately trips the engine-side sanity check in the worker: The is raised inside the encoder runner of the EngineCore worker process with no per-request containment, escapes to the busy loop's top-level handler ( , "EngineCore encountered a fatal error."), triggers at the API server ( ), and the whole process tree shuts down permanently. refuses connections until a manual restart. Verified end-to-end on the official image (id d076d77d8dad) with real weights: after confirming 200, a text chat 200, and two control images (all-white and all-black 1024×1024) 200, the single half-black/half-white request returned HTTP 500 ( ), the engine log shows at , the API server shut itself down, and the container exited ( , ). Every subsequent request, including , fails at the socket. The vulnerable check is unchanged on (verified 2026-09-30 against the raw file on the default branch). **Environment notes (discl
Are you affected?
Enter the version you run. The result uses only the ranges stored on this record.
The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.
- pip vllm>= 0.11.1, < 0.32.0
- pypi vllmversion unspecified
How to fix CVE-2026-115914
Upgrade
CVE-2026-115914 lists a fix boundary at 0.32.0. Compare the installed build with that boundary before you change production.
Version check
Affected < 0.32.0
Advisory
Open the cve_org record and follow its fix.
Official advisories
What to do
Three questions, each answered from this record only. Confirm the vendor advisory before you patch.
Should you patch?
No confirmed exploitation is on record for CVE-2026-115914. EPSS is 0.40%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.
Which versions are affected?
Compare what you have installed with >= 0.11.1, < 0.32.0. Compare the installed version with the linked vendor advisory before you change production.
What should an analyst verify?
CWE-617. EPSS 0.40%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.
Code
The project this record applies to. Exploit listings stay in References.
Timeline
Detection, updates, and resolution for this record.
Oct 26, 2026 · Red Hat Security Data
Detected
vllm: vllm: Denial of service via crafted image input in OCR models
Oct 28, 2026 · GitHub Advisory Database
Updated
## Summary Any vLLM deployment serving a model of the DeepSeek-OCR family — , , or (whose subclasses ) — can be **killed by a single unauthenticated chat request carrying an ordinary, schema-valid PNG image**, under completely default server configuration. The image model's input validation contains a guard inherited from the upstream DeepSeek-OCR reference implementation: In the original research
Sources
- CVE.orgVulnerability recordCVE-2026-115914
Official CVE identifier
cve.org - FIRST EPSSExploitation probabilityCVE-2026-115914
30-day exploitation probability 0.40%
first.org - GitHub Advisory DatabasePackage advisoryGHSA-gq5q-89c7-vhvx
vLLM DeepSeek-OCR image processing vulnerable to denial of service
github.com - GitLab Advisory DatabasePackage advisoryCVE-2026-115914
Any vLLM deployment serving a model of the DeepSeek-OCR family — deepseek-ai/DeepSeek-OCR, deepseek-ai/DeepSeek-OCR-2, or baidu/Unlimited-OCR (whose UnlimitedOCRForCausalLM subclasses DeepseekOCRForCausalLM) — can be killed by a single unauthenticated chat request carrying an ordinary, schema-valid PNG image, under completely default server configuration. The image model's input validation contain
advisories.gitlab.com - Red Hat Security DataVendor advisoryCVE-2026-115914
vllm: vllm: Denial of service via crafted image input in OCR models
access.redhat.com
References
Freshness
Last verified in this catalog Nov 4, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.
- FIRST EPSSNov 4, 2026
- GitHub Advisory DatabaseOct 30, 2026
- GitLab Advisory DatabaseOct 29, 2026
- CVE.orgOct 27, 2026
- Red Hat Security DataOct 27, 2026