Affected: AlmaLinux:9: openexr, AlmaLinux:9: openexr-devel, AlmaLinux:9: openexr-libs
OpenEXR is an open-source high-dynamic-range floating-point image file format for high-quality image processing and storage. This document presents a brief overview of OpenEXR and explains concepts that are specific to this format. This package containes the binaries for OpenEXR.
Security Fix(es):
* OpenEXR: OpenEXR: Arbitrary code execution and information disclosure via crafted EXR file (CVE-2026-34588)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
Affected: Alpaquita:stream: openexr
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.
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…
Affected: openEuler:24.03-LTS: OpenEXR
OpenEXR is a high dynamic-range (HDR) image file format originally developed by Industrial Light & Magic for use in computer imaging applications. Security Fix(es):
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.(CVE-2026-34379)
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t.…
libIex-3_4-33-3.4.9-1.1 on GA media
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…
OpenEXR: OpenEXR: Arbitrary code execution and information disclosure via crafted EXR file
Affected: Rocky Linux:10: openexr
OpenEXR is an open-source high-dynamic-range floating-point image file format for high-quality image processing and storage. This document presents a brief overview of OpenEXR and explains concepts that are specific to this format. This package containes the binaries for OpenEXR.
Security Fix(es):
* OpenEXR: OpenEXR: Arbitrary code execution and information disclosure via crafted EXR file (CVE-2026-34588)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
Security update for openexr
Affected: Ubuntu:Pro:24.04:LTS: openexr, Ubuntu:25.10: openexr, Ubuntu:Pro:26.04:LTS: openexr
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.
Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Red Hat Enterprise Linux (openEXR) ausnutzen, um beliebigen Programmcode auszuführen.