CVE-2026-59183 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. In versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, an int32_t multiplication in OpenEXRCore's unpack_sample_table() can overflow while decoding a crafted deep tiled EXR file, producing an invalid pointer that leads to a read from an unmapped memory address and a crash. Because the overflow occurs in the standard decoding path (exr_decoding_run), any application that decodes deep tiled EXR files is affected. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation for the OpenEXR image format, a high dynamic range file format extensively utilized within the motion picture industry for compositing and visual effects workflows due to its support for deep images and tiled storage structures. The vulnerability identified in versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 resides within the OpenEXRCore library, specifically affecting the decoding logic for deep tiled EXR files. Deep images in this format store multiple samples per pixel at different depths, requiring complex memory allocation and indexing mechanisms to manage the variable data structures efficiently during decompression and unpacking processes.
The technical flaw is rooted in an integer overflow occurring within the unpack_sample_table function when performing a multiplication operation involving int32_t variables. During the decoding of specially crafted deep tiled EXR files, this arithmetic error results in a miscalculated size or offset value that wraps around due to signed integer limitations. This incorrect calculation subsequently leads to the generation of an invalid memory pointer. When the application attempts to access data using this corrupted pointer, it triggers a read from an unmapped memory address, causing the process to terminate abruptly with a segmentation fault or similar crash condition.
From an operational perspective, because this vulnerability is located in the standard decoding path known as exr_decoding_run, any software application that integrates OpenEXRCore and processes deep tiled EXR files is susceptible to denial of service attacks. An attacker can exploit this by distributing maliciously crafted EXR files designed to trigger the integer overflow during routine image loading operations. This impacts not only desktop applications used in post-production but also server-side rendering pipelines or automated processing systems that ingest such media assets, potentially disrupting critical workflows and causing data loss if unsaved work is involved.
This vulnerability aligns with CWE-190, which describes Integer Overflow or Wraparound, as the root cause of the memory corruption leading to the crash. In terms of attack vectors, it corresponds to ATT&CK technique T1496, Resource Hijacking, specifically under the sub-category of Denial of Service via resource exhaustion or system instability caused by malformed input processing. The exploitation does not require user interaction beyond opening or loading the file within a vulnerable application version, making it particularly dangerous in environments where files are processed automatically or from untrusted sources.
Mitigation strategies primarily involve upgrading to patched versions of the OpenEXR library, specifically versions 3.2.11, 3.3.13, and 3.4.14 or later, which include fixes for the integer overflow check in the unpack_sample_table function. For applications unable to immediately update their dependencies, implementing input validation at the ingestion layer can provide a temporary defense-in-depth measure by rejecting EXR files with suspiciously large depth values or tile configurations that might trigger the arithmetic anomaly before they reach the core decoding logic. Additionally, enabling memory protection mechanisms such as Address Sanitizer during development and testing phases can help identify similar integer handling issues in custom integrations of the library.