CVE-2026-34588 — OpenEXR has a signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write

Affected: AcademySoftwareFoundation openexr, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions, Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions, Red Hat Enterprise Linux 9.4 Extended Update Support, Red Hat Enterprise Linux 9.6 Extended Update Support, Red Hat AI Inference Server 3.3, Red Hat Enterprise Linux 6 and 2 more

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9, internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic. Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.

GHSA-588r-cr5c-w6hf — OpenEXR has a signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write

Affected: PyPI: OpenEXR

## Summary

`internal_exr_undo_piz()` advances the working wavelet pointer with signed 32-bit arithmetic:

```c wavbuf += nx * ny * wcount; ```

Because `nx`, `ny`, and `wcount` are `int`, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes.

Tested on commit 7820b7e1b93405ba1d551c43a945018226b75bc5

## Technical Details

The vulnerable decode path is:

1. `internal_exr_undo_piz()` sets `wavbuf = decode->scratch_buffer_1`. 2. For each channel, it calls `wav_2D_decode (wavbuf + j, ...)`. 3. It then advances `wavbuf` with `wavbuf += nx * ny * wcount`.

The overflow happens in step 3. Once `wavbuf` is wrapped, the next channel's wavelet decode runs on the wrong address.

In the 14-bit wavelet path, `wdec14_4()` first reads:

- `*px` - `*p10` - `*p01` - `*p11`

and then writes back to the same locations:

- `*px = ...` - `*p01 = ...` - `*p10 = ...` - `*p11 = ...`

As a result, the bug is not just a crash-only invalid read. It is an out-of-bounds read/write condition.

## Reproduction

[piz_scanline_redzone.zip](https://github.com/user-attachments/files/26318946/piz_scanline_redzone.zip)

Build `exrcheck` with ASAN and run:

``` ❯ ./build-asan/bin/exrcheck /tmp/piz_scanline_redzone.exr file /tmp/piz_scanline_redzone.exr /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:373:19: runtime error: signed in…

Most recent entries from all

CVE-2026-34588 — OpenEXR has a signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write

GHSA-588r-cr5c-w6hf — OpenEXR has a signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write