CVE-2026-27622
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk10th percentile - higher than 10% of all known CVEs
Summary
In the OpenEXR library, a vulnerability exists in the CompositeDeepScanLine::readPixels function where per-pixel totals are accumulated in a vector of unsigned int, allowing an attacker to cause a wrap-around modulo 2^32. This leads to undersized buffer allocation and subsequent buffer overflow during data write operations.
Risk Assessment
The risk for the organization includes potential remote code execution or application crash when processing EXR images, which could compromise data integrity and system availability.
Recommendation
Immediately update the OpenEXR library to version 3.2.6, 3.3.8, or 3.4.6 depending on the branch in use. After updating, restart all services that depend on the library.
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-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. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector<unsigned int> total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.