Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-08-25T18:17:56.910Z",
  "pubdate": "2026-08-25T18:17:56.910Z",
  "executiveSummary": "An out-of-bounds read vulnerability exists in the OpenEXR reference implementation, specifically affecting ILP32 architecture builds. The vulnerability originates within the OpenEXRCore library during the processing of uncompressed deep-tile EXR files.\nThe root cause is an integer wrap-around vulnerability occurring during the calculation of the sample-count table size within decoding.c. By providing a specially crafted EXR file, an attacker can influence the decoder's memory allocation and iteration logic.\nSuccessful exploitation of this flaw can result in a denial of service (DoS) by causing the application to perform invalid memory access. This vulnerability affects OpenEXR versions 3.2.x before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13.\nThe vulnerability requires no authentication or special privileges; however, it necessitates that the target system is running an ILP32-based build of OpenEXR. Users are advised to upgrade to the patched versions to mitigate the risk of application crashes and potential memory disclosure scenarios.",
  "technicalDetails": "The vulnerability resides in the OpenEXRCore library, specifically within the decoding logic located in 'decoding.c'. The flaw is triggered during the handling of uncompressed deep-tile EXR data, where the decoder performs arithmetic operations to determine the size of the sample-count table.\nOn ILP32 (32-bit) architectures, the pointer size and integer widths interact such that the calculation of the sample-count table size is susceptible to integer wrap-around. When a crafted EXR image is processed, the attacker supplies malicious tile dimensions that cause the internal size calculation to overflow or wrap around. This effectively under-allocates the memory buffer intended to store sample counts for the deep-tile data.\nThe attack flow proceeds as follows: 1) An attacker crafts a malicious deep-tile EXR file with specific header dimensions designed to trigger the arithmetic wrap-around. 2) The victim application utilizes the OpenEXRCore library to decode this file. 3) The 'unpack_sample_table()' function is invoked, which attempts to iterate over the decoded tile dimensions based on the corrupted, under-allocated size value. 4) Because the iteration logic assumes a larger buffer than what was actually allocated due to the integer wrap, the function performs an out-of-bounds read while attempting to parse the attacker-controlled tile data.\nThe vulnerable code path involves the interaction between the library's metadata parsing and the subsequent memory management routines. Because 'unpack_sample_table()' relies on the results of the overflowed calculation, it reads memory addresses beyond the bounds of the allocated heap chunk. Depending on the memory layout of the host process, this out-of-bounds access typically triggers a segmentation fault or an access violation, leading to an immediate denial of service.\nThis vulnerability is strictly limited to platforms using ILP32 data models where 32-bit arithmetic is used for index and size calculations. While the primary impact noted is a denial of service, out-of-bounds read vulnerabilities in image processing libraries can theoretically be leveraged in complex scenarios to leak sensitive memory contents if the application persists or crashes in a manner that reveals heap state. However, the immediate security impact is the interruption of service for any application relying on the OpenEXR library for image ingestion or processing, such as renderers, compositors, or viewing utilities."
}