CVE-2026-59983 Overview
CVE-2026-59983 is an out-of-bounds read vulnerability in OpenEXR, the reference implementation for the EXR image format used across the motion picture industry. The flaw affects ILP32 builds where a size calculation in OpenEXRCore/decoding.c wraps around before the sample table is fully iterated. A crafted uncompressed deep-tile EXR file triggers this integer overflow during decoding, leading to denial of service. The issue is classified as [CWE-125] Out-of-Bounds Read and requires user interaction to open a malicious file. Fixed releases are 3.2.11, 3.3.13, and 3.4.14.
Critical Impact
An attacker-supplied deep-tile EXR file processed by a vulnerable ILP32 build of OpenEXR can cause an out-of-bounds read and application crash, resulting in denial of service for image processing pipelines.
Affected Products
- OpenEXR versions prior to 3.2.11
- OpenEXR versions 3.3.0 through 3.3.12
- OpenEXR versions 3.4.0 through 3.4.13 (ILP32 builds)
Discovery Timeline
- 2026-08-25 - CVE-2026-59983 published to NVD
- 2026-08-25 - Last updated in NVD database
Technical Details for CVE-2026-59983
Vulnerability Analysis
The vulnerability resides in the deep-tile decoding path of the OpenEXRCore library. When OpenEXR processes a deep-scanline or deep-tiled chunk, decoding.c computes the sample-count table size by multiplying the chunk width and height. On ILP32 platforms, size_t is 32 bits, so this multiplication can wrap for large attacker-controlled tile dimensions.
After the wrapped value passes size validation, unpack_sample_table() iterates over the full uncapped dimensions. The mismatch between the truncated allocation size and the actual iteration count drives reads beyond the allocated buffer, producing a crash and denial of service in host applications that link OpenEXR.
Root Cause
The root cause is a numeric truncation error during size computation. The original code used size_t arithmetic for width * height * sizeof(int32_t), which overflows silently on 32-bit systems. No overflow check gated the value before it was compared to sample_count_table_size and passed to downstream unpack logic.
Attack Vector
Exploitation requires local access and user interaction: a victim must open or process a crafted EXR file with a vulnerable ILP32 build. The confidentiality and integrity impacts are none; only availability is affected. The attack surface is any tool or rendering pipeline that ingests untrusted EXR content on 32-bit builds.
if (stortype == EXR_STORAGE_DEEP_SCANLINE ||
stortype == EXR_STORAGE_DEEP_TILED)
{
- size_t sampsize =
- (((size_t) decode->chunk.width) * ((size_t) decode->chunk.height));
+ uint64_t sampsize64 =
+ ((uint64_t) decode->chunk.width) * ((uint64_t) decode->chunk.height);
if ((decode->decode_flags & EXR_DECODE_SAMPLE_COUNTS_AS_INDIVIDUAL))
- sampsize += 1;
- sampsize *= sizeof (int32_t);
+ sampsize64 += 1;
+ sampsize64 *= sizeof (int32_t);
+ if (sampsize64 != (size_t) sampsize64) return EXR_ERR_OUT_OF_MEMORY;
+ size_t sampsize = (size_t) sampsize64;
if (decode->chunk.sample_count_table_size == sampsize)
{
Source: OpenEXR patch commit 0efec58. The fix promotes the size calculation to uint64_t, then rejects any value that does not fit into a native size_t with EXR_ERR_OUT_OF_MEMORY.
Detection Methods for CVE-2026-59983
Indicators of Compromise
- Crashes or abnormal termination in processes that link libOpenEXR or libOpenEXRCore when opening EXR files.
- Deep-tile or deep-scanline EXR files with unusually large width or height chunk attributes that overflow 32-bit arithmetic.
- Segmentation faults originating in unpack_sample_table() on 32-bit builds.
Detection Strategies
- Inventory installed OpenEXR versions across build systems, render farms, and workstations to identify versions below 3.2.11, 3.3.13, or 3.4.14.
- Enable AddressSanitizer or equivalent memory instrumentation in test pipelines that ingest untrusted EXR content to surface out-of-bounds reads.
- Monitor endpoint telemetry for repeated crashes of image-processing utilities such as exrheader, exrinfo, or renderer plugins.
Monitoring Recommendations
- Alert on unexpected termination signals from imaging services processing user-submitted content.
- Track ingestion of EXR files from external or untrusted sources through content-inspection gateways.
- Log OpenEXR library version metadata in application startup telemetry to accelerate exposure assessment.
How to Mitigate CVE-2026-59983
Immediate Actions Required
- Upgrade OpenEXR to 3.2.11, 3.3.13, or 3.4.14, matching the branch currently deployed.
- Prioritize remediation on ILP32 (32-bit) builds; 64-bit builds are not affected by the specific truncation path.
- Rebuild and redistribute internal tools and plugins that statically link OpenEXR.
Patch Information
The fix is implemented across three commits in the AcademySoftwareFoundation OpenEXR repository. It rewrites the sample-count size calculation using uint64_t arithmetic and returns EXR_ERR_OUT_OF_MEMORY when the result cannot be represented as size_t. See commit 0efec58, commit 78e9114, commit f0e404f, and the GitHub Security Advisory GHSA-p42q-g5c9-mh9w.
Workarounds
- Migrate 32-bit hosts processing untrusted EXR content to 64-bit builds where feasible until patches are applied.
- Restrict deep-tile EXR ingestion to trusted sources and validate width and height chunk attributes before decoding.
- Sandbox EXR decoding in a separate process so that a crash does not disrupt the host application or pipeline.
# Verify installed OpenEXR version against fixed releases
pkg-config --modversion OpenEXR
# Example: rebuild an ILP32 target against a patched OpenEXR source
git clone https://github.com/AcademySoftwareFoundation/openexr.git
cd openexr
git checkout v3.4.14 # or v3.3.13 / v3.2.11 depending on branch
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --target install
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
