CVE-2026-65979 in OpenEXR
Summary
by MITRE • 08/25/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation and specification for the OpenEXR image format, a high dynamic range imaging standard extensively utilized within the motion picture industry for visual effects and compositing workflows. The vulnerability identified affects versions of the library ranging from 3.4.0 through 3.4.12, specifically targeting the HTJ2K decoder component which handles JPEG 2000 codestreams encapsulated within OpenEXR files. This technical flaw arises during the parsing phase where the decoder processes chunk headers embedded in compressed data streams. The core issue lies in the handling of a header-length field designated as PLEN, which dictates the size of specific header structures required for decoding subsequent image data.
The fundamental technical deficiency is an absence of bounds checking on this attacker-controlled input value. When the HTJ2K decoder encounters the PLEN field within a chunk's compressed data, it extracts the integer value representing the header length without verifying whether this magnitude exceeds the boundaries of the currently allocated memory buffer. Instead of validating that the sum of the current pointer position and the specified header size remains within the limits of the available buffer space, the code proceeds to execute arithmetic operations based on the untrusted input. This lack of validation allows an adversary to supply a crafted EXR file containing a maliciously large PLEN value that artificially inflates the expected data length beyond what is actually present in memory.
Upon processing this malformed header size, the decoder advances its internal codestream pointer by the attacker-supplied amount. Because no boundary check was performed prior to this advancement, the resulting offset frequently points past the end of the allocated buffer region. The library then passes this invalid offset along with a remaining length calculation to the OpenJPH memory-input path for further decoding operations. This sequence directly triggers an out-of-bounds read condition, where the application attempts to access memory locations that are not part of the intended data structure. Such memory violations can lead to information disclosure if sensitive data residing in adjacent memory regions is leaked through the decoded output or error messages, and may potentially facilitate denial of service conditions depending on how the operating system handles the illegal memory access.
From a classification perspective, this vulnerability aligns with CWE-125, which describes Out-of-bounds Read vulnerabilities where software reads data past the end, or before the beginning, of the intended buffer. In terms of attack vectors and techniques, this flaw is relevant to ATT&CK technique T1083, File and Directory Discovery, as it enables an attacker to potentially read arbitrary memory contents from a target system by exploiting the decoder's behavior when processing untrusted media files. The reachability of this issue during normal decoding operations means that simply opening or previewing a maliciously crafted EXR file in a vulnerable version of OpenEXR can trigger the exploit without requiring additional user interaction beyond loading the asset into memory.
To mitigate this risk, organizations and developers must ensure they are operating on patched versions of the library where these bounds checks have been implemented. The issue was resolved in version 3.4.13 by introducing rigorous validation logic that verifies the header length against available buffer constraints before advancing pointers or passing data to downstream decoding components. Until an upgrade is feasible, defensive measures should include implementing strict input sanitization at the application layer and utilizing sandboxing techniques to limit the potential impact of memory corruption events if a vulnerable version must remain in use for legacy compatibility reasons.