CVE-2026-59984 Overview
CVE-2026-59984 is an out-of-bounds write vulnerability in OpenEXR, the reference implementation of the EXR image format used across the motion picture industry. The flaw affects OpenEXR versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 when compiled as ILP32 builds. A crafted B44-compressed scanline EXR file causes the logical scratch size to truncate before allocation, and uncompress_b44_impl() then writes using an attacker-controlled channel width. Exploitation leads to memory corruption and denial of service. The maintainers fixed the issue in versions 3.2.11, 3.3.13, and 3.4.14.
Critical Impact
A crafted B44-compressed EXR file processed by an ILP32 OpenEXR build triggers an out-of-bounds write in uncompress_b44_impl(), causing memory corruption and denial of service.
Affected Products
- OpenEXR 3.1.0 through 3.2.10 (ILP32 builds)
- OpenEXR 3.3.0 through 3.3.12 (ILP32 builds)
- OpenEXR 3.4.0 through 3.4.13 (ILP32 builds)
Discovery Timeline
- 2026-08-25 - CVE-2026-59984 published to NVD
- 2026-08-25 - Last updated in NVD database
Technical Details for CVE-2026-59984
Vulnerability Analysis
The vulnerability resides in the B44 decompression path of OpenEXR. B44 is a lossy compression scheme applied per-channel to scanline EXR images. On ILP32 builds, where long and pointer types are 32 bits, size computations that would remain safe on LP64 targets can wrap or truncate. When OpenEXR calculates the scratch buffer size required to decompress a B44 block, the arithmetic truncates before the allocation call. The subsequent call to uncompress_b44_impl() then writes to the undersized buffer using channel dimensions taken directly from the attacker-controlled EXR header.
This condition is classified as an out-of-bounds write [CWE-787]. The result is heap memory corruption in the decoder process, typically crashing the host application. Because OpenEXR is embedded in rendering pipelines, media players, compositors, and thumbnailers, any workflow that automatically parses untrusted EXR files can trigger the bug.
Root Cause
The root cause is an integer truncation in the scratch-size computation on ILP32 targets. The logical byte count needed to hold decompressed channel data exceeds what a 32-bit size type can represent for large channel widths. The truncated value is passed to the allocator, producing a buffer smaller than the loop bounds later used by uncompress_b44_impl(). The loop writes beyond the allocation because it derives its stride and length from the untrusted channel width in the file header.
Attack Vector
Exploitation requires an attacker to deliver a crafted EXR file and have a victim open or process it with an ILP32 OpenEXR build. This is a local attack vector with user interaction. The attacker does not need prior authentication. Confidentiality and integrity are not directly impacted, but availability is high because the process reliably crashes or corrupts state.
Verified proof-of-concept code is not published in the enriched data. See the GitHub Security Advisory GHSA-92pq-9qv4-g68q for technical details.
Detection Methods for CVE-2026-59984
Indicators of Compromise
- Unexpected crashes or heap corruption alerts in processes that link against OpenEXR (libOpenEXR, libIlmImf), including image viewers, render nodes, and DCC tools.
- Newly introduced or externally sourced .exr files exhibiting unusually large channel width fields or B44 compression flags.
- Application logs referencing uncompress_b44_impl or B44 decoder frames in stack traces at time of crash.
Detection Strategies
- Inventory endpoints and build systems for ILP32 (32-bit) binaries linking OpenEXR versions prior to 3.2.11, 3.3.13, or 3.4.14.
- Use file-format inspection tools such as exrinfo to flag EXR files declaring B44 compression with abnormally large channel dimensions.
- Correlate crash telemetry from media-processing services with recent ingest of untrusted EXR content.
Monitoring Recommendations
- Monitor EDR telemetry for repeated crashes of image-processing daemons, thumbnailers, or render workers handling EXR content.
- Track ingestion pipelines for EXR files sourced from external partners, email attachments, or user uploads.
- Alert on core dumps or ASan reports naming OpenEXR symbols in the B44 decompression path.
How to Mitigate CVE-2026-59984
Immediate Actions Required
- Upgrade OpenEXR to 3.2.11, 3.3.13, or 3.4.14 depending on the deployed branch.
- Rebuild and redistribute any first-party applications that statically link vulnerable OpenEXR versions.
- Restrict processing of untrusted EXR files on ILP32 systems until patched builds are deployed.
Patch Information
The OpenEXR maintainers released fixes in the following versions:
Refer to the GitHub Security Advisory GHSA-92pq-9qv4-g68q for the full advisory.
Workarounds
- Prefer LP64 (64-bit) builds of OpenEXR where feasible, as the truncation condition is specific to ILP32 targets.
- Sandbox EXR decoding in a low-privilege process to contain memory corruption to a disposable worker.
- Validate EXR headers before decoding and reject files declaring B44 compression with channel widths outside expected production ranges.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
