CVE-2026-45696
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk18th percentile — higher than 18% of all known CVEs
Summary
In OpenEXR versions 3.4.0 through 3.4.11, a heap-buffer-overflow READ vulnerability exists in the ht_undo_impl() function of the HTJ2K decoder. The issue arises from missing validation of the OpenJPH line buffer size against the declared EXR channel width, leading to deterministic crashes (DoS) and potential adjacent heap leak.
Risk Assessment
An attacker can exploit a crafted EXR file to cause application crashes (denial of service) or potentially leak heap memory, posing a risk to systems processing untrusted EXR files such as thumbnailers, asset pipelines, and the exrcheck utility.
Recommendation
Immediately update OpenEXR to version 3.4.12 or later, which contains the fix. In the meantime, avoid opening EXR files from untrusted sources.
Original NVD description (English source)
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line->i32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.