Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft malicious .jph codestream with small precincts
-
DeliveryDeliver file to OpenJPH decode path
-
ExploitDecoder processes one-row codeblock
-
ExecutionCleanup-pass writes past buffer
-
ImpactHeap memory corrupted, application crashes
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, write limits
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the victim application to decode an attacker-supplied JPEG 2000 codestream (.j2c or .jph) using OpenJPH version 0.32.0 or earlier. The crafted file must specify small precinct sizes that create degenerate one-row codeblocks processed by the HTJ2K cleanup-pass decoder - this specific malformed structure is the trigger. Limiting factors: the vector is local (AV:L) and requires user/application interaction to open or process the file (UI:P), so there is no remote unauthenticated path; realistic exposure depends on OpenJPH being embedded in a decode path that accepts untrusted images (upload handlers, viewers, conversion services). No authentication is required (PR:N), but a victim must be induced to process the malicious codestream. |
| Impact | This is a moderate, not top-priority, issue whose signals are internally consistent. The authoritative CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:H, score 6.9 Medium) describes a locally-delivered, low-complexity flaw that requires passive user interaction (the victim must decode an attacker-supplied codestream) and whose dominant impact is availability (VA:H, i.e. crashes) with only limited integrity impact (VI:L) and no confidentiality loss (VC:N). This profile matches the description: a heap out-of-bounds WRITE (CWE-787) in the HTJ2K cleanup-pass decoder triggered by degenerate one-row codeblocks. A public PoC (hackmd write-up) exists and the issue was reported by VulnCheck, so publicly available exploit code exists - but there is NO CISA KEV listing and NO EPSS score in the provided data, so there is no evidence of active, widespread exploitation. No SSVC decision data was supplied. The most important caveat: although this is a memory-corruption WRITE primitive (which can sometimes be escalated to code execution), the official vector caps the integrity impact at Low and emphasizes availability, so the realistic outcome is denial of service / crash rather than confirmed RCE. Note also AV:L - this is not a remote-unauthenticated network flaw; an attacker must get a crafted file to a decoder, so exposure depends heavily on whether a product embeds OpenJPH in an internet-facing decode path. |
| Exploit ScenarioDerived | An attacker crafts a malicious .j2c or .jph JPEG 2000 codestream using small precinct sizes that produce one-row (degenerate) codeblocks, then delivers it to a system or service that decodes images with OpenJPH (e.g. an upload endpoint, viewer, or thumbnailing pipeline). When the victim application decodes it, the HTJ2K cleanup-pass decoder writes a second row past the codeblock buffer, corrupting heap memory and crashing the process. A public proof-of-concept write-up is available, lowering the barrier to reproduction. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 15, 2026
Heap out-of-bounds write in OpenJPH 0.32.0 and earlier allows memory corruption when the library decodes a crafted JPEG 2000 codestream (.j2c or .jph) that uses small precinct sizes to create degenerate one-row codeblocks; the HTJ2K cleanup-pass decoder then writes a second row beyond the end of the codeblock buffer, causing heap corruption and crashes. Publicly available exploit code exists, including a detailed technical write-up, but there is no indication of confirmed active exploitation (no CISA KEV listing), and the assessed attack vector is local with user interaction (CVSS 3.1 AV:L/AC:L/PR:N/UI:R, integrity impact low, availability impact high). Realistic exposure requires OpenJPH to sit in a decode path that accepts untrusted images, such as an upload handler, image viewer, or batch conversion service, where a victim is induced to open the malicious file.
RemediationAI
No vendor-released patch version is identified in the available intelligence at time of analysis, so the primary action is to check the upstream OpenJPH repository (https://github.com/aous72/OpenJPH) and the VulnCheck advisory for a release newer than 0.32.0 and upgrade or rebuild all linked/vendored copies as soon as one is published. Until then, apply compensating controls: validate codestreams before decoding by parsing the SIZ/COD markers and rejecting files that declare very small precinct sizes or that would produce one-row (degenerate) codeblocks - this blocks the documented trigger but will reject some legitimate HTJ2K images, so it should be paired with clear error handling rather than silent failure; restrict which components accept .j2c/.jph input (for example, block or disable image import in untrusted upload paths) at the cost of reduced functionality; and run the decoder in a sandboxed, low-privilege worker process with strict memory limits so that a successful write results in a contained crash instead of code execution or persistent corruption. Because exploit code and a full write-up are public, prioritize patching any internet- or tenant-facing decode service, and monitor for crash/restart patterns in decoding workers as a detection signal in the interim.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
OpenJPH is an open-source implementation of High-Throughput JPEG 2000 (HTJ2K, ISO/IEC 15444-15), the low-complexity block-coding variant of the JPEG 2000 standard, and is commonly embedded in image decoders, viewers and conversion pipelines. The flaw is a CWE-787 out-of-bounds write in the HTJ2K cleanup-pass block decoder: when a codestream's COD/SIZ markers specify small precinct sizes, the derived codeblock geometry collapses to a single-row (degenerate) codeblock, yet the cleanup-pass row loop still emits a second row of reconstructed samples. Because the sample buffer for that codeblock was sized from the degenerate geometry, the second row is written past the allocation, corrupting adjacent heap memory. The referenced source locations trace the path directly: subband/codeblock geometry derivation in ojph_subband.cpp (lines 136-142), codeblock buffer handling in ojph_codeblock.cpp (lines 79-84), and the cleanup-pass write loop in ojph_block_decoder32.cpp (lines 1135-1155), all at commit 23c422895ce6c3a156935222e4715ee0b7be952c. This is a decoder-side memory-safety bug rather than a logic or cryptographic weakness, so the practical failure modes are heap corruption, crashes and denial of service, with adjacent-heap tampering possible in principle but unproven.
Know when Openjph gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
File must reach a local decoder and be processed (AV:L, UI:R); no privileges needed (PR:N); OOB write yields partial integrity (I:L) and crashes (A:H) with no confidentiality loss (C:N).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
OpenJPH through 0.32.0 contains a heap out-of-bounds write vulnerability in the HTJ2K cleanup-pass decoder that allows attackers to corrupt memory via one-row codeblocks. Attackers can supply a crafted .j2c or .jph codestream with small precinct sizes, causing the decoder to write a second row past the codeblock buffer, resulting in memory corruption and crashes.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
EUVD-2026-102278
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB