Vulnerability Monitor

The vendors, products, and vulnerabilities you care about

CVE-2026-45696


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.


Security Impact Summary

This vulnerability carries a MEDIUM severity rating with a CVSS v3.1 score of 6.5, indicating it can be exploited remotely over the network with relatively low complexity without requiring user interaction requiring only low-level privileges . The vulnerability impacts and availability (service disruption) for affected systems. Impacting 1 product from openexr organizations running these solutions should prioritize assessment and patching.

Historical Context

Reported in 2026, this vulnerability emerged during an era marked by increased sophistication in supply chain attacks, cloud infrastructure vulnerabilities, and software-as-a-service (SaaS) security challenges. Security practices during this period emphasized zero-trust architectures, container security, and API protection.


Published

2026-06-18T21:16:28.917

Last Modified

2026-07-15T02:22:05.827

Status

Modified

Source

[email protected]

Severity

CVSSv3.1: 6.5 (MEDIUM)

Weaknesses
  • Type: Secondary
    CWE-122
  • Type: Secondary
    CWE-125

Affected Vendors & Products
Type Vendor Product Version/Range Vulnerable?
Application openexr openexr < 3.4.12 Yes

References

How SecUtils Interprets This CVE

SecUtils normalizes and enriches National Vulnerability Database (NVD) records by standardizing vendor and product identifiers, aggregating vulnerability metadata from both NVD and MITRE sources, and providing structured context for security teams. For openexr's affected products, we extract Common Platform Enumeration (CPE) data, Common Weakness Enumeration (CWE) classifications, CVSS severity metrics, and reference data to enable rapid vulnerability prioritization and asset correlation. This record contains no exploit code, proof-of-concept instructions, or attack methodologies—only defensive intelligence necessary for patch management, risk assessment, and security operations.