CVE-2026-65979: OpenEXR: Out-of-bounds read in HTJ2K decoder from unvalidated chunk header length (PLEN)
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenEXR HTJ2K decoderto a version that resolves this vulnerability.Fixed in 3.4.13
Event History
Frequently Asked Questions
Which deployments are affected?
OpenEXR versions 3.4.0 through 3.4.12 are affected when they decode EXR files containing HTJ2K-compressed chunk data. The issue is fixed in OpenEXR 3.4.13.
What does an attacker need to exploit this issue?
An attacker needs to supply a crafted EXR file with an attacker-controlled PLEN value in compressed chunk data and have the target decode it. No special configuration is described; the vulnerable path is reachable during normal decoding of an untrusted file.
What is the practical impact during decoding?
The crafted header length can advance the codestream pointer beyond the available buffer, causing an out-of-bounds read in the OpenJPH memory-input path.
What should be done if untrusted EXR files must be processed?
Upgrade to OpenEXR 3.4.13. Until upgrading is possible, avoid decoding untrusted EXR files that may contain HTJ2K-compressed chunk data.