CVE-2026-59985 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 3.2.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 are vulnerable on ILP32 builds to a heap out-of-bounds read. The issue occurs when a crafted RLE-compressed EXR causes the 64-bit unpacked size to truncate before allocation in OpenEXRCore decoding.c and unpack_32bit() reads beyond the resulting buffer, allowing denial of service. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation for the EXR image format, a standard extensively utilized within the motion picture industry for high-dynamic-range imaging and visual effects workflows. The library processes complex compression algorithms to handle large pixel data efficiently, which is critical for rendering pipelines that process gigabytes of imagery daily. In specific builds targeting ILP32 architectures, where integer, long, and pointer types are all 32 bits wide while the system may be running on a 64-bit processor or operating system, a critical arithmetic vulnerability exists within the decoding logic. This architectural mismatch creates an environment where data type truncation can occur during size calculations, leading to memory safety violations that compromise application stability.
The technical flaw resides in the handling of Run-Length Encoded (RLE) compressed EXR files when processed by OpenEXRCore functions such as unpack_32bit() and related decoding routines. When a maliciously crafted RLE-compressed file is parsed, the library calculates the expected uncompressed size of the data buffer required for decompression. Due to the ILP32 constraint, this calculated 64-bit unpacked size undergoes truncation when assigned or processed within 32-bit variables before memory allocation occurs. Consequently, the system allocates a significantly smaller heap buffer than what is actually needed to hold the uncompressed pixel data. When the decompression routine subsequently attempts to write into this undersized buffer, it triggers an out-of-bounds read operation as it accesses memory locations beyond the allocated boundary.
This vulnerability primarily results in a denial of service condition rather than arbitrary code execution or information disclosure. The heap out-of-bounds read corrupts memory state and typically causes the application processing the EXR file to crash immediately upon encountering the malformed input. For studios relying on automated batch processing systems, this can halt rendering pipelines, cause data loss if unsaved work is involved, or require manual intervention to clear corrupted cache files. While the impact is largely limited to availability in most standard configurations, repeated exploitation could potentially be leveraged for more severe attacks depending on how the host application handles memory errors and whether additional protections like Address Sanitization are disabled during development builds.
From a classification perspective, this issue aligns with CWE-190 Integer Overflow or Wraparound, as the root cause is the incorrect handling of numeric values that exceed the capacity of their data type, leading to an undersized allocation. It also maps to CWE-125 Out-of-bounds Read, describing the actual memory access violation resulting from the insufficient buffer size. In terms of adversary tactics, this vulnerability supports ATT&CK technique T1499 Endpoint Denial of Service, where attackers use malformed inputs to disrupt normal operations without necessarily gaining persistent access or exfiltrating data. The specific context involves exploiting a parsing engine in widely deployed creative software suites, making it relevant for supply chain attacks targeting media production environments.
Mitigation strategies focus primarily on upgrading the OpenEXR library to patched versions that correct the arithmetic handling and buffer allocation logic. Users should update to version 3.2.11 or later within the 3.2 series, version 3.3.13 or later for the 3.3 branch, and version 3.4.14 or newer for the 3.4 release line. These updates include checks that prevent truncation errors during size calculation and ensure buffers are allocated with sufficient capacity to accommodate the full uncompressed data stream. For organizations unable to immediately patch their dependencies, implementing input validation at the application layer to reject suspiciously large RLE headers before they reach the OpenEXR decoder can provide a temporary defense-in-depth measure. Additionally, enabling memory protection mechanisms such as heap randomization and stack canaries in production builds may help mitigate the impact of any residual vulnerabilities by making exploitation more difficult, although upgrading remains the definitive solution.