CVE-2026-34378: 
NixOS vulnerability analysis and mitigation

CVE-2026-34378 is a signed integer overflow vulnerability in OpenEXR's generic_unpack() function that allows an attacker to cause a denial of service by supplying a maliciously crafted EXR file. It affects OpenEXR versions 3.4.0 through 3.4.8, and was disclosed on April 5–6, 2026 by researcher "pwn2woot" via the Academy Software Foundation's GitHub security advisory. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is a missing bounds check on the dataWindow attribute parsed from EXR file headers (CWE-190: Integer Overflow or Wraparound; CWE-20: Improper Input Validation). When dataWindow.min.x is set to a large negative value (e.g., 0xC0000014 = -1,073,741,804), OpenEXRCore computes an enormous image width (~1 billion pixels) via the formula width = dataWindow.max.x - dataWindow.min.x + 1. This width is later used in a signed integer multiplication at unpack.c:1278 (srcbuffer += w * bpc), where w * bpc exceeds INT32_MAX, triggering undefined behavior and a SIGILL signal via UBSan. On systems with memory overcommit enabled, the ~6 GB allocation succeeds, allowing execution to reach the overflow point (GitHub Advisory).

Successful exploitation causes the target process to terminate with a SIGILL signal, resulting in a denial of service. Any application using OpenEXRCore to parse untrusted EXR files is affected, including image editors, 3D renderers, compositing tools, and media processing pipelines. There is no confidentiality or integrity impact; the vulnerability is limited to availability (GitHub Advisory).

1. Craft a malicious EXR file: Start with any valid single-part scanline EXR file using NONE compression and at least two channels (HALF + FLOAT).
2. Modify the header: Using a hex editor or binary manipulation tool, locate the dataWindow.min.x field in the EXR file header and set it to a large negative value such as 0xC0000014 (-1,073,741,804).
3. Deliver the file: Provide the crafted EXR file to a target user or application that uses OpenEXRCore for parsing — for example, by uploading it to a media processing service, embedding it in a document, or sending it via email/messaging.
4. Trigger the crash: When the application opens the file, OpenEXRCore computes an enormous image width (~1 billion pixels), allocates ~6 GB of memory (succeeding on systems with overcommit), and then executes the overflow at unpack.c:1278 (srcbuffer += w * bpc), causing SIGILL and process termination.
5. Reproduce with fuzzer harness (for testing): Compile with clang -fsanitize=address,undefined -o harness fuzz_exr_pipeline.c -lopenexr and run ./harness < poc.exr to observe the crash at generic_unpack() (GitHub Advisory).

• Process: Target application (image editor, renderer, compositing tool) crashes unexpectedly with a SIGILL (Illegal Instruction) signal when opening an EXR file; crash stack trace referencing generic_unpack() at unpack.c:1278 and exr_decoding_run() at decoding.c:664.
• Logs: Application crash logs or core dumps showing SIGILL with stack frames in generic_unpack, exr_decoding_run, or decode_scanline_part; UBSan output indicating signed integer overflow at unpack.c:1278.
• File System: Presence of EXR files with anomalously large computed image dimensions (e.g., dataWindow.min.x set to values near INT32_MIN); suspicious EXR files received from external or untrusted sources.
• Memory: Unusual memory allocation spikes (~6 GB) associated with EXR file parsing processes prior to crash (GitHub Advisory).

Upgrade OpenEXR to version 3.4.9 or later, which includes the fix for CVE-2026-34378 along with several other security patches released on April 3, 2026. Until patching is possible, restrict processing of EXR files from untrusted sources and implement input validation on EXR file headers before passing them to OpenEXRCore. Downstream distributions including openSUSE, Fedora, and Amazon Linux 2023 have issued updated packages (OpenEXR v3.4.9 Release, Red Hat CVE).

Red Hat tracked the vulnerability via Bugzilla and assessed it as medium severity, with downstream package updates issued for affected distributions. openSUSE and Fedora both issued security announcements and updated packages shortly after disclosure. No notable independent researcher commentary or significant social media discussion has been identified beyond standard vulnerability tracking (Red Hat CVE, openSUSE Security).