CVE-2026-26981: 
Python vulnerability analysis and mitigation

CVE-2026-26981 is a heap-buffer-overflow vulnerability (via signed integer underflow) in OpenEXR's istream_nonparallel_read function in ImfContextInit.cpp, triggered when parsing a malformed EXR file through a memory-mapped IStream. It affects OpenEXR versions 3.3.0–3.3.6 and 3.4.0–3.4.4. The advisory was published by the maintainer on February 21, 2026, and registered in the NVD on February 24, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, OpenEXR Advisory).

The root cause is a signed-to-unsigned conversion error (CWE-195) in ImfContextInit.cpp at lines 121–136. When the bounds check nend > stream_sz is triggered, the code incorrectly computes sz = stream_sz - nend, which yields a negative int64_t value (e.g., 21 - 4113 = -4092). Because sz is of type size_t (unsigned), this negative value wraps around to a near-maximum value (~0xFFFFFFFFFFFFF004), which is then passed directly to memcpy, causing a heap-buffer-overflow (OOB read). The fix, applied in commits 6bb2ddf and d2be382, corrects the calculation to sz = static_cast<size_t>(stream_sz - nread) and adds explicit static_cast conversions to prevent implicit sign conversion. Exploitation requires user interaction — a victim must open a crafted EXR file using an application backed by a memory-mapped IStream (OpenEXR Advisory, Patch Commit).

Successful exploitation causes an immediate crash of any application that opens the crafted EXR file, resulting in a denial of service (high availability impact). There is no confidentiality or integrity impact — the vulnerability cannot be used to read sensitive data or modify system state. The scope is limited to applications using an IStream implementation where isMemoryMapped() returns true, which is common in media production pipelines and image processing tools that use OpenEXR (OpenEXR Advisory, Github Advisory).

A proof-of-concept (PoC) exploit — including a minimal 21-byte malformed EXR file and C++ reproducer code — was published as part of the official security advisory (OpenEXR Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.025% (7th percentile), indicating a low probability of near-term exploitation (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Craft a malformed EXR file: Create a specially crafted EXR file where the file size is very small (e.g., 21 bytes) but the tile/header attributes reference a read size that, when added to the current read position (nread), exceeds the actual stream size. The published PoC uses the byte sequence {0x76, 0x2f, 0x31, 0x01, 0x02, 0x06, 0x00, 0x00, 0x74, 0x69, 0x6c, 0x65, 0x73, 0x00, 0x20, 0x00, 0x00, 0x53, 0x00, 0x00, 0x00}.
2. Deliver the file to the target: Distribute the malformed EXR file via email attachment, file share, web upload, or any channel where a user or automated pipeline would open it with a vulnerable OpenEXR-based application.
3. Trigger parsing via memory-mapped IStream: The victim opens the file using an application that uses a memory-mapped IStream (i.e., isMemoryMapped() returns true). This triggers istream_nonparallel_read in ImfContextInit.cpp during header parsing.
4. Trigger the integer underflow: During bounds adjustment, sz = stream_sz - nend computes a negative int64_t (e.g., -4092), which is implicitly cast to size_t, wrapping to ~0xFFFFFFFFFFFFF004.
5. Crash via heap-buffer-overflow: memcpy is called with the wrapped size, causing an out-of-bounds read and immediate application crash (denial of service) (OpenEXR Advisory).

• Application Behavior: Sudden, reproducible crash of any application (e.g., image viewers, VFX tools, media pipelines) when opening a specific EXR file; crash occurs immediately upon file open without rendering any content.
• Logs: AddressSanitizer (ASAN) output containing negative-size-param errors referencing ImfContextInit.cpp:136 and __asan_memcpy; crash dumps or core files generated by the affected process.
• File System: Presence of unusually small (e.g., ~21-byte) or structurally malformed .exr files in directories processed by the application; files that do not conform to valid EXR format structure.
• Process: Abnormal termination (SIGABRT, SIGSEGV) of processes linked against OpenEXR versions 3.3.0–3.3.6 or 3.4.0–3.4.4 when processing EXR input (OpenEXR Advisory).

Upgrade to OpenEXR version 3.3.7 (for the 3.3.x branch) or 3.4.5 (for the 3.4.x branch), which contain the corrected size calculation in ImfContextInit.cpp. No configuration-based workaround is available; the only effective mitigation is patching. As an interim measure, restrict processing of EXR files from untrusted or external sources, and monitor for application crashes related to EXR file parsing. Downstream distributions including Fedora (mingw-openexr) and Chainguard/Wolfi have also issued updated packages (OpenEXR Advisory, Patch Commit).

The vulnerability was credited to researcher JungWooJJING and disclosed responsibly through GitHub's security advisory process. Splunk issued an advisory (SVD-2026-0309) referencing this CVE, indicating downstream impact on Splunk products. Fedora issued updates for mingw-openexr across Fedora 42, 43, and 44. Community coverage has been limited, consistent with the moderate severity and DoS-only impact of the vulnerability.