CVE-2026-107080: 
Ghostscript vulnerability analysis and mitigation

CVE-2026-107080 is a heap buffer out-of-bounds read and write vulnerability in OpenJPEG's reversible (5/3) forward Discrete Wavelet Transform (DWT) encoder, specifically in the opj_dwt_encode_and_deinterleave_v() function in src/lib/openjp2/dwt.c. It affects OpenJPEG versions 2.4.0 through 2.5.4 and git master through commit 8314119b; versions 2.3.1 and earlier use a different vertical pass implementation and are not affected. The vulnerability was privately reported by Red Eagle Tech on September 27, 2026, publicly disclosed on October 5, 2026, and assigned a CVE on October 24, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (Red Hat Advisory, GitHub Issue).

The root cause is a missing height-zero guard in opj_dwt_encode_and_deinterleave_v(), classified as CWE-787 (Out-of-bounds Write) and CWE-125 (Out-of-bounds Read). The vulnerable code path was introduced by commit a38e970fa59abd796c703ec469e578b09f7ffa33 ("Forward DWT 5-3: major speed up by vectorizing vertical pass", 2020-05-22) and first released in version 2.4.0. When a tile's resolution level has zero height — which occurs when image dimensions, tile size, and decomposition level count cause two tile edges to coincide under opj_int_ceildivpow2() — opj_dwt_encode_procedure() still invokes the vertical pass with height == 0. At an odd start (cas_col = l_cur_res->y0 & 1), the function's else branch executes with sn == dn == 0 and accesses tmp[NB_ELTS_V8 + c] (lines 1658 and 1716 on master), which lies 0 bytes past the end of the 32-byte scratch buffer. AddressSanitizer confirms a heap-buffer-overflow at dwt.c:1658 and dwt.c:1716; in plain Release builds, repeated encodes in a single process trigger a glibc heap-corruption abort (SIGABRT). The sibling function opj_dwt_encode_and_deinterleave_v_real() (irreversible 9/7 path) is not affected (GitHub Issue, oss-security).

Successful exploitation causes a denial of service: applications that encode more than one image in a single process will be aborted by glibc's heap-corruption detection (SIGABRT, exit 134) after the heap metadata is corrupted by the out-of-bounds write. A single encode of the triggering geometry exits cleanly and round-trips byte-identically, making the issue invisible to single-image pipelines. There is no confirmed confidentiality or integrity impact on the encoded codestream; the researchers explicitly state they make no claim about exploitability beyond the abort (oss-security, GitHub Issue).

No confirmed in-the-wild exploitation has been observed, and no standalone weaponized exploit or proof-of-concept attack tool exists. The GitHub issue (#1673) contains detailed vulnerability analysis, AddressSanitizer output, and a reproducer script, but NVD's SSVC assessment classifies it as "poc" with "no" automatability, reflecting that user interaction (processing a specially crafted or parameterized encode) is required. The EPSS score is 0.00185 (approximately 0.19th percentile), indicating low near-term exploitation probability. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog. The triggering geometry requires control over encoding parameters (image dimensions, tile size, decomposition levels) rather than a crafted input file, limiting the attack surface to applications that accept attacker-supplied encoding parameters (Feedly, GitHub Issue).

1. Identify target: Find an application that uses libopenjp2 for encoding and accepts attacker-influenced parameters such as image dimensions, tile size (-t), or number of decomposition levels (-n).
2. Craft triggering geometry: Construct an image whose dimensions, tile size, and decomposition level count cause a resolution level to have zero height. A minimal example is a 1×6 PGM image encoded with -t 4,5 -n 3 (tile width 4, tile height 5, 3 decomposition levels), which causes rh == 0 at a lower resolution level with an odd vertical start.
3. Trigger the encode: Submit the crafted parameters to the target application so it calls opj_compress or the equivalent library API. A single encode exits 0 and appears successful.
4. Achieve denial of service: Cause the application to perform the same encode (or another triggering encode) a second time within the same process. The out-of-bounds write corrupts glibc heap metadata, causing the process to abort with Fatal glibc error: malloc.c:2599 (sysmalloc): assertion failed (SIGABRT, exit 134) (GitHub Issue, oss-security).

• Process: Application process using libopenjp2 terminates unexpectedly with SIGABRT (exit code 134) or logs Fatal glibc error: malloc.c:2599 (sysmalloc): assertion failed or corrupted size vs. prev_size.
• Logs: AddressSanitizer output (if enabled) showing heap-buffer-overflow at opj_dwt_encode_and_deinterleave_v in dwt.c:1658 or dwt.c:1716, with the message READ of size 4 at ... 0 bytes after 32-byte region.
• Core dumps: Core dump files from the encoding application process, generated after repeated JPEG 2000 encode operations with unusual image geometry (very small dimensions combined with large decomposition level counts).
• Application behavior: Encoding of a single image succeeds and round-trips correctly, but the application crashes on a subsequent encode within the same session (GitHub Issue, oss-security).

The fix is a four-line patch adding an early-return guard (if (height == 0) { return; }) at the top of opj_dwt_encode_and_deinterleave_v() in src/lib/openjp2/dwt.c, proposed in pull request #1674. Users should apply this patch or update to a version of OpenJPEG that incorporates it once merged. As a workaround, avoid processing untrusted or attacker-controlled encoding parameters (image dimensions, tile size, decomposition levels) with affected versions. The OpenJPEG project README has declared the project unmaintained as of July 2026, so distributors and packagers may need to carry the patch independently (GitHub PR, oss-security, Red Hat Bugzilla).

Red Eagle Tech, the discovering organization, followed responsible disclosure practices by privately notifying the upstream maintainer on September 27, 2026, with a seven-day window, before publicly disclosing on October 5, 2026 via a GitHub issue, pull request, and oss-security mailing list post. The oss-security post noted that the OpenJPEG project had declared itself unmaintained in July 2026, explicitly warning packagers that they may need to carry the patch themselves. Red Hat tracked the issue via Bugzilla (Bug 2560888) with medium severity. No significant broader media coverage or social media discussion has been identified (oss-security, Red Hat Bugzilla).