CVE-2026-68514
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk8th percentile - higher than 8% of all known CVEs
Summary
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.
Risk Assessment
Opening a malicious EXR file via the Python API can lead to memory corruption and application crash, posing a threat to system stability.
Recommendation
Update OpenEXR to version 3.3.13 or 3.4.14, which include the fix.
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-42216Critical
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.
- 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-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.
- CVE-2026-65979Medium
OpenEXR versions 3.4.0-3.4.12 have an out-of-bounds read vulnerability in the HTJ2K decoder because it does not check if the header-length field (PLEN) fits within the available buffer. A crafted EXR file can cause an out-of-bounds read.
Original NVD description (English source)
OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, the PyOpenEXR Python bindings contain a heap out-of-bounds write triggered when reading a crafted deep scanline EXR file. When a deep file declares a literal channel named left alongside layer-prefixed RGB channels left.R, left.G, and left.B, the wrapper processes the literal left channel first and allocates a scalar deep sample array for it, then reuses that same array as the coalesced destination for the prefixed RGB group. The deep reader registers sample slices with an RGB stride (three lanes) into storage that was allocated with scalar shape, so decoding the deep samples writes past the allocation. Opening such a file through the default public Python API, OpenEXR.File(path), causes a heap buffer overflow during normal deep sample decode, leading to memory corruption and a crash. This issue is fixed in versions 3.3.13 and 3.4.14.