CVE-2026-34380: 
NixOS vulnerability analysis and mitigation

CVE-2026-34380 is a signed integer overflow vulnerability in the PXR24 decompression decoder of OpenEXR that may allow a bounds-check bypass, leading to an out-of-bounds write. It affects OpenEXR versions 3.2.0–3.2.6, 3.3.0–3.3.8, and 3.4.0–3.4.8. The vulnerability was published on April 6, 2026, and was reported by researcher "pwn2woot" via the Academy Software Foundation's security advisory process. It carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory, Red Hat).

The root cause is a signed integer overflow (CWE-190) in undo_pxr24_impl() within src/lib/OpenEXRCore/internal_pxr24.c at line 377, which can lead to an out-of-bounds write (CWE-787). The expression (uint64_t)(w * 3) evaluates w * 3 as a signed 32-bit integer before casting to uint64_t; for specific large values of w (e.g., w = 1431655766), two's-complement wraparound produces a small positive integer (e.g., 2), causing the subsequent bounds check nDec + (uint64_t)(w * 3) > outSize to pass incorrectly. If bypassed, the decoding loop writes 4 * w bytes through the dout pointer, potentially far beyond the allocated output buffer. The same overflow pattern also corrupts the nDec decoded-byte counter on line 389, and analogous expressions exist in the HALF and UINT pixel-type branches of the same function. Exploitation requires a crafted EXR file using PXR24 compression with a FLOAT channel and a specific dataWindow width value that survives upstream header and chunk-size validations (GitHub Advisory).

Successful exploitation causes a confirmed denial of service (application crash) under sanitized builds, and theoretically enables heap out-of-bounds writes that could corrupt memory and potentially lead to arbitrary code execution depending on allocator behavior and memory layout. Any application that decodes untrusted PXR24-compressed EXR files is affected, including media processing pipelines, VFX tools, and image viewers used in the motion picture industry. There is no confidentiality impact, but integrity is rated low and availability is rated high due to the crash potential (GitHub Advisory, Red Hat).

1. Craft a malicious EXR file: Create an EXR image file using PXR24 compression with a FLOAT pixel-type channel. Set the dataWindow to produce a channel width value w where w * 3 overflows a signed 32-bit integer and wraps to a small positive value (e.g., w = 1431655766 / 0x55555556, where w * 3 wraps to 2 under two's-complement arithmetic).
2. Ensure the crafted w value passes upstream validation: The EXR header and chunk-size validation must not reject the crafted width. This is the primary barrier to full exploitation and has not been publicly confirmed as bypassed.
3. Deliver the file to a target application: Trick a user or automated pipeline into opening the crafted .exr file using a vulnerable OpenEXR version (3.2.0–3.2.6, 3.3.0–3.3.8, or 3.4.0–3.4.8). This requires user interaction (e.g., opening a file in a VFX tool or image viewer).
4. Trigger the integer overflow: When the application calls undo_pxr24_impl(), the expression (uint64_t)(w * 3) overflows, producing a small value that causes the bounds check at line 377 to pass incorrectly.
5. Achieve out-of-bounds write: The decoding loop executes w iterations, writing 4 * w bytes of attacker-influenced pixel data through dout beyond the allocated output buffer, causing a crash (DoS) or potential heap corruption (GitHub Advisory).

• File System: Presence of unexpected or externally sourced .exr files using PXR24 compression with anomalous dataWindow dimensions (extremely large width values near integer overflow boundaries).
• Process: Application crashes or abnormal termination of processes that consume EXR files (e.g., VFX tools, image viewers, media processing daemons); core dumps or crash reports referencing undo_pxr24_impl, internal_exr_undo_pxr24, exr_uncompress_chunk, or exr_decoding_run in stack traces.
• Logs: UBSan/ASan runtime error messages such as signed integer overflow: ... * 3 cannot be represented in type 'int' in application logs; repeated EXR_ERR_CORRUPT_CHUNK errors followed by unexpected crashes.
• Network: Unusual delivery of .exr files via email attachments, web downloads, or shared storage from untrusted sources to systems running OpenEXR-dependent applications (GitHub Advisory).

Upgrade OpenEXR to the patched versions: 3.2.7, 3.3.9, or 3.4.9, depending on the currently deployed branch (OpenEXR v3.2.7, OpenEXR v3.3.9, OpenEXR v3.4.9). The fix changes the vulnerable expression from (uint64_t)(w * 3) to (uint64_t)w * 3 (casting before multiplication) on both lines 377 and 389 of internal_pxr24.c. As interim workarounds, restrict processing of EXR files from untrusted sources, implement application sandboxing to limit the impact of potential memory corruption, and monitor for crashes or unusual memory access patterns in applications using OpenEXR (GitHub Advisory). Distribution-level patches have been issued for openSUSE, Fedora, Ubuntu (USN-8259-1), Amazon Linux 2023, and FreeBSD.

The vulnerability was reported by researcher "pwn2woot" and disclosed responsibly through the Academy Software Foundation's GitHub security advisory process. Red Hat tracked it via Bugzilla (Bug 2455384) and rated it medium severity. Multiple Linux distributions including openSUSE, Fedora, Ubuntu, and Amazon Linux 2023 issued security advisories and package updates shortly after disclosure. No notable public researcher commentary or significant social media discussion beyond standard vulnerability tracking has been observed (Red Hat Bugzilla, GitHub Advisory).