CVE-2025-59732: OpenEXR Buffer Overflow Vulnerability

CVE-2025-59732 Overview

CVE-2025-59732 is a heap-based out-of-bounds write vulnerability in OpenEXR, the high dynamic range image file format library. The flaw exists in the decoder logic for files compressed with DWAA or DWAB compression schemes. The decoder assumes that image height and width are divisible by 8, but it allocates the td->uncompressed_data buffer using the precise image dimensions. When dimensions are not a multiple of 8, the copy loops write past the allocated bounds and corrupt adjacent heap memory. Successful exploitation can lead to memory corruption and potentially arbitrary code execution when a victim processes a crafted OpenEXR file. The maintainers recommend upgrading to OpenEXR version 8.0 or later.

Critical Impact
Processing a malicious OpenEXR file using DWAA or DWAB compression triggers a heap buffer overflow, enabling memory corruption with potential for code execution.

Affected Products

OpenEXR versions prior to 8.0 that include DWAA/DWAB decoding
Applications and image pipelines that link against vulnerable OpenEXR libraries
Visual effects, rendering, and compositing tools that ingest untrusted EXR files

Discovery Timeline

2025-10-06 - CVE-2025-59732 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-59732

Vulnerability Analysis

The flaw is classified under [CWE-787] Out-of-Bounds Write. OpenEXR's DWAA and DWAB compression codecs decode pixel data in 8x8 tiles. The decode_block routine allocates the destination buffer td->uncompressed_data using the exact pixel height and width of the image. The subsequent copy loops, however, iterate up to the next multiple of 8 without checking the true buffer length. When an attacker crafts an EXR file with a width or height that is not divisible by 8, the loops write beyond the allocated buffer. The overflow corrupts neighboring heap chunks and can be shaped to influence control flow or adjacent object metadata.

Root Cause

The root cause is a mismatch between buffer allocation and loop iteration bounds. Allocation uses the actual image dimensions, while the decode loops use rounded-up multiples of 8 derived from the DWAA/DWAB block layout. The decoder lacks a bounds check before writing the tail of each partial tile.

Attack Vector

An attacker delivers a malicious OpenEXR image to a victim application that uses the vulnerable decoder. Delivery paths include rendering pipelines, asset ingestion services, web preview generators, and desktop image viewers. User interaction is required to open or process the file. The vulnerability is triggered locally by the decoder once the file is parsed.

No verified public proof-of-concept code is available. See the Google Issue Tracker entry for technical details on the decoder logic and reproduction conditions.

Detection Methods for CVE-2025-59732

Indicators of Compromise

OpenEXR files reporting image dimensions that are not divisible by 8 while declaring DWAA or DWAB compression
Crashes or heap corruption signatures in processes that load libOpenEXR or equivalent bindings
Unexpected child processes spawned by image viewers, renderers, or asset pipelines after parsing EXR files

Detection Strategies

Inspect EXR headers at ingress and flag files with DWAA/DWAB compression and non-aligned dimensions for sandbox analysis
Monitor for SIGSEGV, heap allocator aborts, or ASan reports in services that decode user-supplied images
Inventory installed versions of OpenEXR across endpoints, build systems, and container images to identify vulnerable instances

Monitoring Recommendations

Enable application crash telemetry on workstations used by VFX, animation, and rendering teams
Alert on process behavior anomalies originating from image preview or thumbnail generation services
Correlate file-type telemetry with EDR process telemetry to detect exploitation attempts during EXR parsing

How to Mitigate CVE-2025-59732

Immediate Actions Required

Upgrade OpenEXR to version 8.0 or later across all systems and rebuild dependent applications
Audit container images, build pipelines, and third-party software for bundled OpenEXR libraries and update them
Restrict EXR file ingestion to trusted sources until patches are deployed

Patch Information

The OpenEXR maintainers recommend upgrading to version 8.0 or beyond. Vendors that ship OpenEXR bindings or static copies must rebuild their products against the patched library. Reference the Google Issue Tracker entry for fix details.

Workarounds

Disable DWAA and DWAB compression code paths in custom builds where image dimension validation cannot be enforced
Process untrusted EXR files inside sandboxed or containerized environments with strict resource limits
Reject EXR files whose declared width or height is not a multiple of 8 at the ingestion layer until libraries are patched