EUVD-2026-44580
GHSA-hr36-79f7-75x7
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
File-parsing library, so decode of an attacker-supplied image is needed (UI:R); no auth on the code path (PR:N) and a single malformed file triggers it (AC:L), yielding full memory-corruption impact.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
4DescriptionCVE.org
Buffer Overflow vulnerability in OpenHTJ2K v.0.18.4 and before allows an attacker to execute arbitrary code via the j2k_precinct_subband::parse_packet_header() in source/core/coding/coding_units.cpp
AnalysisAI
Arbitrary code execution in OpenHTJ2K (an open-source High Throughput JPEG 2000 codec by osamu620) versions 0.18.4 and earlier stems from an unchecked coding-pass counter overflowing the fixed pass_length[128] array while parsing crafted JPEG 2000 packet headers. An attacker who supplies a malicious J2K/HTJ2K image to an application built on the library can corrupt adjacent memory and potentially execute code. No public exploit identified at time of analysis; EPSS is low (0.20%) and CISA SSVC rates current exploitation as none, though technical impact is total and the flaw is automatable.
Technical ContextAI
OpenHTJ2K implements the ISO/IEC 15444-15 High Throughput JPEG 2000 (HTJ2K) codestream format in C++. The defect is in j2k_precinct_subband::parse_packet_header() in source/core/coding/coding_units.cpp, which decodes the per-codeblock packet-header syntax of a JPEG 2000 tile. For each codeblock the parser reads a segment_passes value from the untrusted stream and accumulates it into block->num_passes, which indexes a fixed-size pass_length[128] array. Because the running total was cast straight into a uint8_t with no bounds check, an attacker-controlled pass count could exceed 128 (and wrap the 8-bit counter), driving writes past the end of the array. This is the CWE-121 stack-based buffer overflow class (write beyond a fixed-length buffer using an attacker-influenced length); note the vendor's own fix comment describes it as a heap buffer overflow in pass_length[128], so the exact memory region depends on how the codeblock object is allocated.
RemediationAI
Update OpenHTJ2K past the fixed commit 0778b93, which adds a kMaxCodingPasses=128 bound and throws before num_passes can exceed the pass_length[] array; confirm the exact patched release on the project's releases page (https://github.com/osamu620/OpenHTJ2K/releases) and CHANGELOG (https://github.com/osamu620/OpenHTJ2K/blob/main/CHANGELOG), since a released patched version is not independently confirmed from the provided data - the fix is currently traceable to a commit rather than a tagged version. If you cannot rebuild immediately, the practical compensating control is to stop feeding untrusted JPEG 2000/HTJ2K input to the library: gate decoding behind validation or sandbox the decoder process (seccomp/container) so an overflow cannot escalate, and disable or restrict any automated/server-side ingestion of externally supplied .j2k/.jph files. These controls reduce exposure but block or slow legitimate JPEG 2000 processing, so scope them to untrusted sources. Verify your build includes the fix via https://github.com/osamu620/OpenHTJ2K/compare/0778b93...v0.18.4.
Same weakness CWE-121 – Stack-based Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today