CVE-2026-59186 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 before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, a crafted tiled EXR can trigger a heap out-of-bounds write on 32-bit/ILP32 builds when read through the public TiledRgbaInputFile RGBA API. The file uses a small 40x40 dataWindow but a 65537x65537 tile size. On ILP32, the Array2D<Rgba> tile-conversion buffer size calculation overflows, allocates a much smaller heap buffer, and tile decode writes past that allocation. 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 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 provides robust tools for reading and writing these complex image files, including APIs designed to handle tiled data structures efficiently. However, in versions prior to 3.2.11, as well as in the ranges 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, a critical memory safety vulnerability exists within the public TiledRgbaInputFile RGBA API. This flaw allows an attacker to trigger a heap out-of-bounds write by supplying a specially crafted EXR file, potentially leading to arbitrary code execution or application crashes depending on the runtime environment and exploitation context.
The technical root cause of this vulnerability lies in integer overflow during buffer size calculation for tiled image decoding. Specifically, when processing a tile-conversion buffer using an Array2D structure, the library calculates the required heap allocation based on dimensions provided in the file header. A maliciously constructed EXR file can specify a modest dataWindow, such as 40x40 pixels, while simultaneously declaring an excessively large tile size of 65537 by 65537 tiles. On systems utilizing ILP32 data models, which are common in many 32-bit environments and certain embedded or legacy systems, the multiplication required to calculate the total buffer size results in a signed integer overflow. This arithmetic error causes the calculated allocation size to wrap around to a significantly smaller value than actually needed for safe decoding operations.
Consequently, the application allocates a heap buffer that is far too small to hold the decoded tile data. When the decoder proceeds to write pixel data into this undersized buffer based on the actual dimensions implied by the file structure, it writes past the end of the allocated memory region. This out-of-bounds write corrupts adjacent heap metadata or application data structures. Such corruption can be leveraged by an attacker to achieve arbitrary code execution if they can control the content written beyond the boundary and manipulate subsequent allocations or function pointers stored in nearby memory regions. The vulnerability is strictly tied to 32-bit builds, as larger pointer sizes on LP64 systems would prevent the integer overflow from resulting in such a drastically small allocation size under normal circumstances.
From a classification perspective, this issue aligns with CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Write. In terms of adversary tactics, exploitation could facilitate initial access via maliciously crafted assets delivered through email attachments or compromised websites, mapping to MITRE ATT&CK techniques such as T1204 User Execution if the victim opens a file in an affected viewer, or potentially lateral movement and persistence if used within a larger attack chain involving renderer plugins. The impact is severe because OpenEXR libraries are often embedded in professional graphics applications that process untrusted content from various sources, including clients, collaborators, or public repositories.
Mitigation requires immediate upgrading to patched versions of the library. Specifically, users should upgrade to version 3.2.11 for legacy branches, version 3.3.13 for the 3.3 series, and version 3.4.14 for the latest stable release line. These updates include fixes that properly validate dimension parameters and prevent integer overflows during buffer allocation calculations. For developers integrating OpenEXR into their own applications, it is also advisable to implement input validation at higher levels where feasible and ensure that build environments are aware of potential risks associated with 32-bit architectures when processing external media files. Regular security audits and dependency updates remain essential practices for maintaining the integrity of software pipelines in creative industries.