CVE-2026-59981 in OpenEXR
Summary
by MITRE • 08/25/2026
OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, the OpenEXRUtil library returns an out-of-bounds pointer from the SampleCountChannel::row() API when a deep image has a non-zero dataWindow origin. The row() accessor is documented as 0-based and computes its address from an internal base that is offset for absolute pixel coordinates, so the two coordinate models conflict whenever dataWindow.min is non-zero. For a deep image whose data window has a large negative vertical origin, row(0) points far outside the allocated sample-count buffer. An application that opens an attacker-controlled deep EXR file and accesses sample counts through row() performs an out-of-bounds read, which can crash the process or, under a controlled heap layout, return adjacent heap memory as sample-count values. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The OpenEXR image file format serves as the industry standard for high-dynamic-range imagery, particularly within visual effects and motion picture production pipelines where data integrity is paramount. The vulnerability identified in versions of OpenEXR through 3.2.10, 3.3.12, and 3.4.13 resides specifically within the OpenEXRUtil library, which provides utility functions for parsing and manipulating EXR files. This flaw manifests as an out-of-bounds memory read triggered by a logical error in coordinate system handling when processing deep images with non-zero data window origins. Deep images are a specialized feature of the EXR format that allow multiple samples per pixel to represent varying depths, such as those found in 3D scene renders or volumetric data. The specific function involved is SampleCountChannel::row(), which is designed to return a pointer to an array containing sample counts for a given row index.
The technical root cause of this vulnerability stems from a conflict between two different coordinate models used within the library's internal logic. The row() accessor method operates under a 0-based indexing assumption, meaning it expects input coordinates relative to the start of the image data buffer. However, the underlying memory address calculation relies on an absolute pixel coordinate model that accounts for the dataWindow.min values. When a deep EXR file specifies a non-zero origin in its header, particularly with large negative vertical origins, the internal offset logic fails to correctly align the 0-based row index with the actual allocated buffer location. Consequently, instead of pointing to the beginning of the sample-count array for that specific row, the function returns a pointer significantly displaced from the valid memory region. This displacement results in an out-of-bounds read operation when the application attempts to access or process these counts.
From an operational security perspective, this vulnerability presents significant risks ranging from denial of service to potential information disclosure. If an attacker crafts a malicious EXR file with specific deep image parameters and non-zero data window origins, they can induce a crash in any application that opens the file and subsequently accesses sample count data through the affected API. This constitutes a classic denial-of-service vector against applications relying on OpenEXR for media processing. More critically, under conditions where an attacker has control over heap layout or memory allocation patterns adjacent to the vulnerable buffer, this out-of-bounds read can be leveraged to leak sensitive information from neighboring memory regions. The returned values may contain fragments of other objects in memory, potentially exposing cryptographic keys, user credentials, or internal application state, thereby facilitating further exploitation stages such as arbitrary code execution if combined with additional vulnerabilities like use-after-free conditions.
This issue aligns with Common Weakness Enumeration CWE-125, which describes out-of-bounds read errors resulting from improper validation of array indices or pointer arithmetic. In the context of the MITRE ATT&CK framework, this vulnerability supports reconnaissance and collection techniques where an adversary might extract data from a compromised system through memory scraping facilitated by buffer over-reads. The exploitation path typically involves tricking a victim into opening a specially crafted file via email attachments, shared drives, or integrated software plugins that automatically parse EXR files without sufficient input sanitization.
Mitigation strategies primarily involve upgrading to patched versions of the OpenEXR library, specifically version 3.2.11, 3.3.13, or 3.4.14 and later, where the coordinate mapping logic has been corrected to properly handle non-zero data window origins. For organizations unable to immediately update their dependencies, implementing strict input validation on EXR file headers before processing deep image channels can provide a temporary defense layer. Security teams should also monitor for unusual memory access patterns or crashes in media processing applications and consider deploying runtime application self-protection mechanisms that detect out-of-bounds accesses. Regular auditing of third-party library versions used in creative software pipelines is essential to maintain resilience against such low-level memory safety vulnerabilities.