CVE-2026-45696: OpenEXR HTJ2K Decoder Heap Overflow DoS (v3.4.0–3.4.11)

Technical summary

The vulnerability exists in the ht_undo_impl() function within OpenEXRCore's HTJ2K decoder. The function copies decoded pixel samples from a per-line OpenJPH buffer using the width value advertised in the EXR file header as its iteration count. However, a malformed EXR codestream can declare smaller tile and line dimensions than the header specifies, creating a mismatch. Because ht_undo_impl() does not validate the OpenJPH buffer's actual capacity, it proceeds to read 32-bit samples from cur_line->i32[] beyond the allocated bounds. This results in a 4-byte heap-buffer-overflow READ immediately after memory allocated by ojph::local::codestream::finalize_alloc(). The vulnerability is classified as CWE-122 (Heap-based Buffer Overflow) and CWE-125 (Out-of-bounds Read), and is reachable through standard scanline-decode entry points such as exr_decoding_run() and Imf::checkOpenEXRFile().

Business impact

The denial-of-service impact is broad because EXR file processing is embedded in many production workflows. Asset pipelines, digital asset management systems, and thumbnail indexing services that automatically ingest and preview EXR files can be crashed by a single malicious file. In motion picture and visual effects environments, this can disrupt collaborative work and delay asset validation. The adjacent-heap leak potential, while less immediately severe, may allow information disclosure in confined scenarios. Organizations relying on automated EXR validation or archival systems face operational risk until patching is complete.

Affected systems

OpenEXR versions 3.4.0 through 3.4.11 are affected. The vulnerability is fixed in version 3.4.12. Any application using OpenEXRCore's decoding functions to process untrusted EXR files is at risk, including but not limited to: thumbnail generators, image viewers, asset management platforms, VFX software integrations, and command-line utilities like exrcheck. The threat surface extends to any system that automatically ingests or previews EXR files from external sources.

Exploitability

Exploitation requires only a crafted EXR file and a vulnerable application to open it. The attack vector is network-accessible (CVSS AV:N) and requires no special privileges beyond the ability to cause the application to load a file (PR:L reflects that interaction is needed, such as uploading to an asset system). No user interaction is required once the file is opened. The malformed codestream is deterministic and will reliably trigger the crash, making this a stable denial-of-service vector. However, active exploitation in the wild has not been documented (KEV status: false).

Remediation

Upgrade OpenEXR to version 3.4.12 or later. This release includes validation logic in ht_undo_impl() to confirm that the OpenJPH buffer's declared dimensions match the EXR header specifications before reading. Verify compatibility with dependent libraries and applications in your environment before deploying, as minor version updates can occasionally affect binary compatibility. If immediate patching is not possible, restrict file ingestion from untrusted sources and implement application-level filtering to prevent EXR files from reaching vulnerable code paths.

Patch guidance

Update OpenEXR from any version in the 3.4.0–3.4.11 range to 3.4.12. Check your package manager (apt, homebrew, vcpkg, etc.) for availability; most major distributions should release updates within days of the vendor advisory. For embedded or statically linked OpenEXRCore, rebuild and redeploy affected binaries. Test the update in a staging environment to confirm that dependent software (VFX tools, asset management platforms, image libraries) continues to function. If you maintain a custom build, download the patched source from the official OpenEXR repository and rebuild according to your standard procedures.

Detection guidance

Monitor for crashes in applications that process EXR files, particularly those in automated workflows (asset ingest, thumbnail generation). If using SELinux or AppArmor, enable auditing on heap-overflow signals. Log file ingestion events and correlate crashes with recently added EXR files. In environments with network-based asset pipelines, inspect uploaded EXR files for structural anomalies (mismatched header vs. codestream dimensions) using a local validation tool before automated processing. Runtime memory sanitizers (ASAN) will immediately catch the heap overflow during testing. No known public exploit exists yet, so detection should focus on application stability and post-mortem analysis of crash logs.

Why prioritize this

This vulnerability merits prompt but not emergency patching. The CVSS score of 6.5 (MEDIUM) reflects the high availability impact (DoS) but absence of confidentiality or integrity compromise. Prioritize patching in environments where EXR files are ingested from untrusted sources (web uploads, external pipelines, partner submissions) or where asset infrastructure is critical to production. Organizations using OpenEXR only for in-house, trusted content creation may defer patching if other risk controls are in place, but this is not recommended for public-facing or partner-integrated systems.

Risk score, explained

The CVSS v3.1 score of 6.5 (MEDIUM) is driven by a high availability impact (A:H), reflecting the deterministic denial-of-service condition. Confidentiality and integrity scores are null (N), as the overflow is a read-only operation that crashes rather than corrupts or exfiltrates data. The attack vector is network-accessible (AV:N) and requires low attack complexity (AC:L), making exploitation straightforward with a crafted file. The attack requires some level of privilege or interaction (PR:L), as the file must be opened by an application, but this is a low bar in asset pipeline contexts. The scope is unchanged (S:U), affecting only the vulnerable component and downstream processes.

Frequently asked questions