CVE-2026-42216
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk37th percentile - higher than 37% of all known CVEs
Summary
In OpenEXR versions 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11, a vulnerability exists in the IDManifest::init() function. When reconstructing strings from a prefix-compressed representation, the code reads bytes without verifying that the current string has at least two bytes, potentially causing an out-of-bounds read.
Risk Assessment
This vulnerability could allow an attacker to read data beyond the allocated buffer, potentially leading to disclosure of sensitive information or system instability.
Recommendation
Immediately update OpenEXR to version 3.2.9, 3.3.11, or 3.4.11, depending on the branch in use.
Other vulnerabilities in OpenEXR
See all- CVE-2017-12596High
In OpenEXR 2.2.0, a crafted image causes a heap-based buffer over-read in the hufDecode function in IlmImf/ImfHuf.cpp during exrmaketiled execution; it may result in denial of service or possibly unspecified other impact.
- CVE-2017-9115High
In OpenEXR 2.2.0, an invalid write of size 2 in the = operator function in half.h could cause the application to crash or execute arbitrary code.
- CVE-2017-9113High
In OpenEXR 2.2.0, an invalid write of size 1 in the bufferedReadPixels function in ImfInputFile.cpp could cause the application to crash or execute arbitrary code.
- CVE-2017-9111High
In OpenEXR 2.2.0, an invalid write of size 8 in the storeSSE function in ImfOptimizedPixelReading.h could cause the application to crash or execute arbitrary code.
- CVE-2026-42217Critical
OpenEXR versions from 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11 have an issue with the readVariableLengthInteger() function that decodes a variable-length integer from untrusted EXR input without bounding the shift count. After enough continuation bytes, the code executes a left shift by 70 on a 64-bit value, leading to undefined behavior.
- CVE-2026-88384Medium
OpenEXR 3.4.14 contains a NULL Pointer Dereference in the C++ attribute parsing path. A specially crafted EXR file containing an unknown-type attribute with dataSize set to zero causes the parser to create an opaque attribute with a NULL packed_data pointer. The OpaqueAttribute constructor passes the NULL pointer to memcpy() without validating the zero-size condition, resulting in undefined behavior and process termination.
- CVE-2026-68515High
OpenEXR before versions 3.2.11, 3.3.13, and 3.4.14 contains a vulnerability in the exrmultiview utility that can write past a heap allocation when combining two attacker-supplied, individually valid scanline EXR files whose union dataWindow is not aligned to one view's channel subsampling. This leads to a heap out-of-bounds write.
- CVE-2026-68514Medium
PyOpenEXR versions 3.3.0-3.3.12 and 3.4.0-3.4.13 have a heap out-of-bounds write vulnerability when reading a crafted deep scanline EXR file. A specially crafted file with a 'left' channel and layer-prefixed RGB channels can cause a buffer overflow and crash.
- CVE-2026-68513High
OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 contain a heap buffer overflow in PyOpenEXR triggered by a channel-name key collision between literal and prefixed RGB channels. A crafted EXR file can cause an out-of-bounds write in a NumPy array during pixel decoding.
- CVE-2026-59981High
OpenEXR versions through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 contain a vulnerability in the OpenEXRUtil library that returns an out-of-bounds pointer from the SampleCountChannel::row() API for deep images with a non-zero dataWindow origin. This can lead to an out-of-bounds read, potentially causing a process crash or disclosure of memory data.
Original NVD description (English source)
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From versions 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11, IDManifest::init() reconstructs strings from a prefix-compressed representation. If the previous string is longer than 255 bytes, the next string is expected to begin with a 2-byte prefix length. The code reads stringList[i][0] and stringList[i][1] without checking that the current string has at least two bytes. This issue has been patched in versions 3.2.9, 3.3.11, and 3.4.11.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

