AcademySoftwareFoundation OpenEXR up to 3.4.10 Exrcheck Utility ht_undo_impl i32[] heap-based overflow

Summaryinfo

A vulnerability labeled as critical has been found in AcademySoftwareFoundation OpenEXR up to 3.4.10. Affected by this vulnerability is the function ht_undo_impl of the component Exrcheck Utility. Such manipulation of the argument i32[] leads to heap-based overflow. This vulnerability is traded as CVE-2026-45696. Access to the local network is required for this attack to succeed. There is no exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability was found in AcademySoftwareFoundation OpenEXR up to 3.4.10. It has been rated as critical. Affected by this issue is the function ht_undo_impl of the component Exrcheck Utility. The manipulation of the argument i32[] with an unknown input leads to a heap-based overflow vulnerability. Using CWE to declare the problem leads to CWE-122. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). Impacted is confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at github.com. This vulnerability is handled as CVE-2026-45696 since 05/13/2026. The exploitation is known to be easy. The attack needs to be done within the local network. There are known technical details, but no exploit is available.

The vulnerability scanner Nessus provides a plugin with the ID 321448 (Python Library OpenEXR 3.4.x < 3.4.12 Multiple Vulnerabilities), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 3.4.11 eliminates this vulnerability. The upgrade is hosted for download at github.com.

The vulnerability is also documented in the vulnerability database at Tenable (321448). Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• AcademySoftwareFoundation

Name

• OpenEXR

Version

• 3.4.0
• 3.4.1
• 3.4.2
• 3.4.3
• 3.4.4
• 3.4.5
• 3.4.6
• 3.4.7
• 3.4.8
• 3.4.9
• 3.4.10

License

• open-source

Website

• Product: https://github.com/AcademySoftwareFoundation/openexr/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion