Description
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.
Published: 2026-06-18
Score: 8.3 High
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A heap buffer over-read occurs in the HTJ2K decoder function ht_undo_impl() of OpenEXRCore, allowing a crafted EXR file to trigger a deterministic crash and potential adjacent‑heap data exposure. The decoder copies pixel data from a per‑line buffer based on the EXR channel width declared in the file header without validating the actual decoded line length, causing a four‑byte out‑of‑bounds read immediately after a heap allocation. The flaw results in a failure of the exr_decoding_run or Imf::checkOpenEXRFile entry point, which are used by thumbnailers, asset pipelines, and other consumers of EXR files.

Affected Systems

The Academy Software Foundation’s OpenEXR library, versions 3.4.0 through 3.4.11, is affected. These releases include the HTJ2K decoder that performs the unsafe copy. The problem was fixed in OpenEXR 3.4.12 and newer releases.

Risk and Exploitability

The CVSS score of 8.3 indicates high severity, and the vulnerability is reachable via any routine use of the OpenEXR decoder on untrusted files. Although an EPSS score is not available and the issue is not listed in CISA’s KEV catalog, the deterministic nature of the crash and lack of an input validation check make exploitability high in environments where EXR files are processed without validation.

Generated by OpenCVE AI on June 18, 2026 at 22:24 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade OpenEXR to version 3.4.12 or later, which removes the unsafe buffer copy.
  • Restrict processing of EXR files to trusted sources or proactively validate the file header against the decoded line dimensions before executing the decoder.
  • If an immediate upgrade is not possible, disable the HTJ2K decoding path or block files containing HTJ2K chunks in your ingestion pipeline to prevent the vulnerable routine from executing.

Generated by OpenCVE AI on June 18, 2026 at 22:24 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 18 Jun 2026 21:15:00 +0000

Type Values Removed Values Added
Description 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.
Title OpenEXR HTJ2K decoder heap buffer over-read in ht_undo_impl() (DoS)
Weaknesses CWE-122
References
Metrics cvssV4_0

{'score': 8.3, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H'}

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-06-18T20:31:56.603Z

Reserved: 2026-05-13T04:38:01.164Z

Link: CVE-2026-45696

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-18T22:30:16Z

Weaknesses
  • CWE-122

    Heap-based Buffer Overflow