CVE-2026-59982 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. OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 can return an out-of-bounds pointer from TypedDeepImageChannel::row() when a crafted deep EXR has a nonzero dataWindow origin. This vulnerability occurs because the API combines zero-based row access with an absolute-coordinate-adjusted base pointer, allowing a crash or limited information disclosure. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation and specification for the EXR image format, which has become a standard in the motion picture industry due to its support for high dynamic range imaging and complex data structures. The vulnerability identified affects multiple versions of this library, specifically those prior to version 3.2.11, versions ranging from 3.3.0 through 3.3.12, and versions from 3.4.0 through 3.4.13. This widespread impact underscores the importance of maintaining up-to-date dependencies in applications that process high-fidelity imagery or engage with professional visual effects pipelines where EXR files are routinely exchanged between rendering engines, compositing software, and storage systems.
The core technical flaw resides within the TypedDeepImageChannel::row() function, which is responsible for retrieving specific rows of pixel data from deep image channels. Deep images in the EXR format allow multiple depth values per pixel coordinate, requiring complex memory management to handle variable amounts of data per sample. The vulnerability arises when a crafted malicious EXR file specifies a nonzero origin for its data window. In such cases, the API incorrectly combines zero-based row access logic with an absolute-coordinate-adjusted base pointer. This miscalculation results in the function returning an out-of-bounds memory pointer rather than correctly calculating the offset relative to the actual start of the channel's data buffer.
From a security classification perspective, this issue aligns closely with CWE-125, which describes Out-of-Bounds Read vulnerabilities. By accessing memory outside the intended bounds of the allocated buffer, an attacker can potentially trigger undefined behavior within the application utilizing OpenEXR. The immediate operational impact includes application crashes due to segmentation faults or access violations when the invalid pointer is dereferenced. Furthermore, if the out-of-bounds read occurs in a context where the accessed memory contains sensitive information, it could lead to limited information disclosure. This aligns with ATT&CK technique T1083, File and Directory Discovery, although in this specific instance, the primary risk is stability rather than systematic data exfiltration unless combined with other vulnerabilities or specific exploitation contexts involving heap metadata exposure.
The severity of this vulnerability depends heavily on how OpenEXR is integrated into downstream applications. For standalone viewers that simply display images without further processing, the impact may be limited to denial of service via application termination. However, for automated pipelines in visual effects studios where EXR files are processed programmatically before being passed to other tools, a crash could disrupt production workflows and cause significant downtime. In more complex scenarios involving memory-corrupting exploits or side-channel attacks leveraging timing differences based on the accessed memory location, the risk profile increases significantly.
Mitigation strategies primarily involve upgrading the OpenEXR library to patched versions that correct the pointer arithmetic logic. Specifically, users should upgrade to version 3.2.11 for the 3.2 branch, version 3.3.13 for the 3.3 branch, or version 3.4.14 for the 3.4 branch. These releases contain fixes that properly handle nonzero data window origins by ensuring that row access calculations account for the offset correctly without resulting in out-of-bounds memory references. Additionally, developers integrating OpenEXR should implement robust input validation and sanitization routines to detect malformed EXR files early in the processing pipeline. Employing fuzz testing on image parsers can help identify similar edge cases before they reach production environments. Regularly auditing third-party dependencies for known vulnerabilities remains a critical practice for maintaining the integrity of software systems that handle untrusted media assets.