CVE-2026-59983 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 are vulnerable on ILP32 builds to an out-of-bounds read. The vulnerability is reached when a crafted uncompressed deep-tile EXR causes the sample-count table size calculation in OpenEXRCore decoding.c to wrap before unpack_sample_table() iterates over the full attacker-controlled tile dimensions, allowing denial of service. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
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 EXR image format, a standard deeply entrenched in the motion picture industry for handling high-dynamic-range imagery and complex compositing workflows. The library processes intricate data structures to support features such as deep images, where each pixel can contain multiple depth samples representing different layers of geometry or shading information within a single frame. This complexity introduces significant parsing overhead and requires robust memory management strategies to handle large datasets efficiently across various hardware architectures.
A critical vulnerability exists in OpenEXR versions prior to 3.2.11, as well as in the ranges from 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 when compiled for ILP32 architectures. The flaw manifests specifically during the decoding of uncompressed deep-tile EXR files within the OpenEXRCore library, particularly in the source file decoding.c. When processing these crafted inputs, the software performs a calculation to determine the size of the sample-count table required to store metadata about the depth samples for each pixel in a tile.
The core technical flaw is an integer overflow condition that occurs during this size calculation on ILP32 builds. Because ILP32 systems typically use 32-bit integers for pointer and index types, large values resulting from attacker-controlled tile dimensions can cause the calculated table size to wrap around to a small positive number or zero instead of failing with an appropriate error code indicating insufficient memory. This integer overflow is not caught before the subsequent unpacking phase begins.
Following the flawed calculation, the function unpack_sample_table() proceeds to iterate over the full attacker-controlled tile dimensions using the incorrectly wrapped value as the boundary for array access operations. Since the allocated buffer size corresponds to the small wrapped value rather than the actual required size based on tile dimensions, any iteration beyond this limited range results in an out-of-bounds read operation. This memory violation allows unauthorized access to adjacent heap or stack memory regions that lie outside the intended allocation boundaries.
The operational impact of this vulnerability is primarily a denial of service condition for applications relying on OpenEXR for image processing. When the out-of-bounds read occurs, it typically triggers immediate application crashes due to segmentation faults or undefined behavior exceptions. In environments where EXR files are processed from untrusted sources, such as automated rendering pipelines or online submission portals, this can lead to service disruption and potential instability in downstream systems that depend on consistent availability of image processing services.
This vulnerability aligns with CWE-190, which describes integer overflow or wraparound errors, a common precursor to memory corruption issues. Furthermore, the exploitation vector relates to ATT&CK technique T1496, Resource Hijacking, as an attacker can leverage this flaw to disrupt service availability by causing crashes in processing nodes within a distributed rendering farm or cloud-based image hosting platform.
Mitigation strategies involve upgrading OpenEXR to patched versions that address these integer handling deficiencies. Specifically, users should update to version 3.2.11 for the legacy branch, or version 3.3.13 and 3.4.14 for their respective major releases. These updates include validation checks that prevent the sample-count table size calculation from wrapping around on ILP32 architectures, ensuring that oversized inputs are rejected safely before memory allocation occurs. Additionally, developers integrating OpenEXR should implement input sanitization routines to validate tile dimensions and file structures against expected maximums prior to invoking decoding functions, adding a layer of defense-in-depth protection against malformed or maliciously crafted EXR files.