CVE-2026-34544: 
Python vulnerability analysis and mitigation

CVE-2026-34544 is a signed integer overflow leading to an out-of-bounds write in OpenEXR's B44/B44A decoder (uncompress_b44_impl() in internal_b44.c). A crafted B44 or B44A EXR file can trigger the flaw in any application that decodes it via exr_decoding_run(), resulting in a crash or heap corruption. Affected versions span OpenEXR 3.2.0–3.2.6, 3.3.0–3.3.8, and 3.4.0–3.4.7; patched releases are 3.2.7, 3.3.9, and 3.4.8. The vulnerability was published on March 27, 2026 by the Academy Software Foundation and assigned a CVSS v4 base score of 8.4 (High) and a CVSS v3.1 score of 7.3 (High) (Github Advisory, OpenEXR Advisory).

The root cause is a signed integer overflow (CWE-190) that leads to an out-of-bounds write (CWE-787) in internal_b44.c. The variables nx (channel width) and ny (channel height) are declared as plain int, and while the scratch buffer allocation correctly promotes to uint64_t for sizing, the row pointer arithmetic row0 += y * nx performs the multiplication in int. When nx is sufficiently large (e.g., 268,435,456), the product y * nx exceeds INT_MAX, causing a signed integer overflow that displaces row0–row3 to memory before the scratch buffer. Subsequent memcpy() calls at lines 592–595 then write decoded B44 pixel blocks to these invalid addresses, producing an active out-of-bounds write; the same integer overflow pattern exists in the encoder path (compress_b44_impl), causing an out-of-bounds read. The fix (commit 35e7aa3) computes the row offset as uint64_t row_off = (uint64_t)(y) * (uint64_t)(nx) before pointer arithmetic in both paths (OpenEXR Advisory, Fix Commit).

Successful exploitation causes an out-of-bounds write into heap memory preceding the scratch buffer, with consequences ranging from an immediate application crash (most likely outcome) to corruption of adjacent heap allocations depending on memory layout. In a worst-case scenario, heap corruption could be leveraged for arbitrary code execution within the context of the application processing the malicious EXR file. All three CIA pillars are rated High for the vulnerable system: confidentiality, integrity, and availability are all at risk if code execution is achieved, though no subsequent system impact is expected (Github Advisory, OpenEXR Advisory).

A public proof-of-concept (PoC) written in C is available in the official security advisory; it generates a valid B44 scanline EXR file (268,435,456 × 9 pixels, single HALF channel) and immediately decodes it to trigger the crash (OpenEXR Advisory). The EPSS score is approximately 0.008% (1st percentile), indicating a low current probability of active exploitation. There is no evidence of in-the-wild exploitation or threat actor attribution at this time, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires user interaction — a victim must open or process a malicious EXR file — but no privileges are required on the part of the attacker (Github Advisory).

1. Craft a malicious EXR file: Using the published PoC or a custom tool, create a B44-compressed scanline EXR file with an extremely large channel width (e.g., W = 268,435,456) and a height of at least 9 rows. The key is that y * nx (with y=8 and nx=268435456) must exceed INT_MAX to trigger the overflow.
2. Prepare the payload: Call exr_start_write(), exr_add_part() with EXR_COMPRESSION_B44, exr_add_channel() for a HALF pixel type, and exr_write_scanline_chunk() with crafted packed data to produce the malicious /tmp/poc_b44.exr file.
3. Deliver the file to the target: Distribute the crafted .exr file via email attachment, file share, web upload, or any channel where the target application will open and decode it (e.g., a VFX/compositing tool, image viewer, or media pipeline using OpenEXR 3.2.0–3.2.6, 3.3.0–3.3.8, or 3.4.0–3.4.7).
4. Trigger decoding: When the victim opens the file, the application calls exr_decoding_run(), which invokes uncompress_b44_impl(). The row pointer arithmetic row0 += y * nx overflows int, displacing row0 before the scratch buffer.
5. Achieve crash or heap corruption: The subsequent memcpy() calls write decoded pixel data to the invalid address, causing a segmentation fault (crash) or, depending on heap layout, corrupting adjacent allocations for potential code execution (OpenEXR Advisory).

• File System: Presence of unusually large .exr files (channel width approaching or exceeding 2^28 pixels) in user download directories, temp folders (e.g., /tmp/poc_b44.exr), or application input queues.
• Process: Application crashes (segmentation faults, access violations) in processes that handle EXR files, particularly in functions such as uncompress_b44_impl, internal_exr_undo_b44, decompress_data, exr_uncompress_chunk, or exr_decoding_run visible in crash dumps or core files.
• Logs: ASAN/sanitizer output containing signed integer overflow: 8 * 268435456 cannot be represented in type 'int' or AddressSanitizer: SEGV on unknown address with a WRITE access in memcpy called from uncompress_b44_impl internal_b44.c:599.
• Network: Unexpected inbound delivery of .exr files from untrusted sources to systems running VFX, compositing, or image processing pipelines that use vulnerable OpenEXR versions (OpenEXR Advisory).

The primary remediation is to upgrade OpenEXR to a patched version: 3.2.7, 3.3.9, or 3.4.8 depending on the branch in use (OpenEXR Release, Fix Commit). As a workaround where patching is not immediately possible, restrict EXR file processing to trusted sources only and implement input validation to reject files with channel dimensions that could trigger the overflow (e.g., width ≥ 2^28). Additionally, consider sandboxing applications that decode EXR files (e.g., using seccomp, AppArmor, or containers) to limit the blast radius of any heap corruption. Amazon Linux 2 and 2023, openSUSE, and Fedora have issued updated packages incorporating the fix (Github Advisory).

The vulnerability was reported by researcher nicoppida and patched by the Academy Software Foundation maintainer cary-ilm as part of the v3.4.8 patch release, which also addressed a separate PXR24 buffer overrun (OpenEXR Release). A technical write-up was published on dev.to covering the signed integer overflow and out-of-bounds write mechanics. Downstream Linux distributions including openSUSE, Fedora, and Amazon Linux issued security advisories and updated packages shortly after the upstream fix was released.