CVE-2026-34588: Signed 32-bit Integer Overflow leading to Out-of-Bounds Memory Access in OpenEXR PIZ Decoder

OpenEXR provides the industry-standard specification and reference implementation for the EXR file format used extensively in motion picture production. The OpenEXRCore library, introduced in OpenEXR 3, exposes a low-level C API for handling these EXR files. This library processes various compression schemes, including the PIZ wavelet compression format.

Versions 3.1.0 through 3.4.8 of the OpenEXR library contain an integer overflow vulnerability in the PIZ decompression routine. The specific flaw resides within the internal_exr_undo_piz() function responsible for reconstructing wavelet-compressed image channels. This vulnerability corresponds to CWE-190 (Integer Overflow or Wraparound).

When a maliciously crafted EXR file specifies abnormally large image dimensions, the decompression logic performs unsafe arithmetic operations. This results in the calculation of an invalid memory pointer. Subsequent operations utilize this corrupted pointer, leading to both out-of-bounds read (CWE-125) and out-of-bounds write (CWE-787) conditions.

The root cause of CVE-2026-34588 lies in how the internal_exr_undo_piz() function calculates memory offsets for subsequent image channels. During PIZ decompression, the decoder iterates through each channel and determines the boundaries of the target wavelet buffer. The base pointer for the next channel is incremented using the expression wavbuf += nx * ny * wcount;.

The variables nx (channel width), ny (channel height), and wcount (data type multiplier) are declared as standard signed 32-bit integers (int). Because the multiplication is performed using signed 32-bit arithmetic, the maximum representable positive value is 2,147,483,647 (INT_MAX). If the product of these dimensions exceeds this boundary, a two's complement wrap-around occurs.

When the arithmetic overflows, the resulting value wraps to a negative integer. The program adds this negative offset to the wavbuf pointer, causing it to point backward into previously allocated memory or entirely outside the designated heap segment. The decoder fails to validate this resulting pointer against the expected buffer boundaries.

The vulnerability stems directly from the type declarations in the channel iteration loop. In the vulnerable implementation, the calculation operates strictly within the bounds of standard integers. The compiler emits instructions for 32-bit signed multiplication without checking the overflow flag.

// Vulnerable Code Pattern
int nx = channel_width;
int ny = channel_height;
int wcount = type_multiplier;
// Multiplication performed as signed 32-bit integer
wavbuf += nx * ny * wcount; 

The patch addresses this by promoting the arithmetic operation to use 64-bit unsigned integers. By casting the variables or changing their underlying types to uint64_t, the product can safely accommodate the maximum theoretical dimensions of an EXR image channel without overflowing.

// Patched Code Pattern
uint64_t span_size = (uint64_t)nx * (uint64_t)ny * (uint64_t)wcount;
// explicit bounds check added against total buffer allocation 'outsz'
if (current_offset + span_size > outsz) {
    return EXR_ERR_OUT_OF_MEMORY;
}
wavbuf += span_size;

Furthermore, the patched versions introduce an explicit bounds validation step. The decoder calculates the cumulative size of all channels and verifies that this sum does not exceed the total allocated size of the decompression buffer (outsz). This secondary check ensures that even if the arithmetic is mathematically correct, the pointer remains strictly within the bounds of the allocated heap object.

Exploiting CVE-2026-34588 requires the attacker to deliver a maliciously crafted EXR file to a vulnerable application. The file must declare a PIZ compression scheme and specify extreme dimensions in the channel metadata. The targeted application must then attempt to render or process this image using the vulnerable OpenEXRCore API.

Upon processing the crafted header, the decoder allocates the initial buffers and enters the internal_exr_undo_piz() routine. The integer overflow occurs silently during the calculation of the wavbuf pointer for subsequent channels. The corrupted pointer is subsequently passed as an argument to the wav_2D_decode() function.

The wav_2D_decode() function performs an in-place wavelet transformation. It actively reads from and writes to the memory locations dictated by the corrupted wavbuf pointer. Because the pointer typically wraps to a negative value, the function writes decoding artifacts into memory addresses preceding the allocated buffer.

An attacker manipulates the EXR channel data to control the values written during the wavelet transformation. By aligning the negative offset and controlling the output of the inverse wavelet transform, the attacker overwrites adjacent heap metadata or function pointers. This provides the primitive necessary to hijack execution flow and achieve code execution.

The primary impact of this vulnerability is memory corruption leading to out-of-bounds read and write operations. When the decoder processes data outside the allocated heap chunk, it causes immediate application instability, resulting in a localized denial of service. The CVSS v4.0 base score of 8.6 reflects the severe local impact of this flaw.

In the context of the motion picture industry, OpenEXR files are routinely processed by automated render farms and artist workstations. A malicious file submitted to a rendering queue or opened by a compositor executes the out-of-bounds operations within the context of the rendering application. This execution context often holds significant privileges regarding network storage and intellectual property.

While out-of-bounds memory accesses provide a theoretical pathway to arbitrary code execution, achieving reliable exploitation requires overcoming modern memory mitigation techniques such as ASLR and Heap randomization. The out-of-bounds read primitive provided by the corrupted pointer assists an attacker in locating necessary memory addresses, bypassing ASLR protections prior to executing the out-of-bounds write.

The Academy Software Foundation released patched versions of OpenEXR to address CVE-2026-34588. Organizations must update their OpenEXRCore dependencies to version 3.2.7, 3.3.9, or 3.4.9. Versions prior to 3.1.0 are not affected by this specific implementation flaw, as the vulnerable C API was introduced in the OpenEXR 3 branch.

Software developers distributing applications that statically link OpenEXR must rebuild their binaries with the updated library versions. System administrators should identify all dynamically linked applications relying on system-level libOpenEXRCore packages and apply the corresponding operating system updates.

There are no effective configuration workarounds for this vulnerability short of completely disabling the processing of PIZ-compressed EXR files. Applications that process untrusted EXR files before patching is possible should execute the decoding logic within heavily restricted sandbox environments. Implementing strict pre-validation of image dimensions prior to invoking the OpenEXR API mitigates the attack vector.