CVE-2026-42217
Integer Overflow in OpenEXR Image Processing
Publication date: 2026-05-07
Last updated on: 2026-05-08
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openexr | openexr | From 3.0.0 (inc) to 3.2.9 (exc) |
| openexr | openexr | From 3.3.0 (inc) to 3.3.11 (exc) |
| openexr | openexr | From 3.4.0 (inc) to 3.4.11 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-190 | The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-42217 is a security vulnerability in the OpenEXR library, specifically in the readVariableLengthInteger() function used to decode variable-length integers from untrusted EXR input.
The function does not properly limit the shift count when decoding, which can lead to a left shift by 70 bits on a 64-bit value. This is undefined behavior and can corrupt the parsing process.
An attacker can craft a malicious EXR file with an idmanifest attribute that triggers this overflow, causing corrupted return values that are then used as string-list lengths, potentially leading to out-of-bounds reads.
The vulnerability was patched by rejecting encodings that require shifts of 64 or more bits and by enforcing stricter validation on string lengths to prevent out-of-bounds indexing.
How can this vulnerability impact me? :
This vulnerability can lead to undefined behavior during the parsing of EXR files, which may cause memory corruption or out-of-bounds reads.
Such memory corruption can potentially be exploited to cause application crashes, denial of service, or even arbitrary code execution depending on how the corrupted data is used.
If you use OpenEXR to process untrusted or maliciously crafted EXR files, your systems could be at risk of these impacts.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves a flaw in the OpenEXR library's readVariableLengthInteger() function when parsing untrusted EXR files, specifically in the IDManifest attribute. Detection involves identifying usage of vulnerable 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) and monitoring for suspicious or malformed EXR files that could trigger the undefined behavior.
To detect exploitation attempts or presence of vulnerable versions on your system, you can:
- Check the installed OpenEXR library version using package management commands, for example:
- On Debian/Ubuntu: dpkg -l | grep openexr
- On RedHat/CentOS: rpm -qa | grep openexr
- On systems with pkg-config: pkg-config --modversion OpenEXR
To detect suspicious EXR files that might exploit this vulnerability, you can use file inspection or scanning tools to identify EXR files with potentially malformed IDManifest attributes, although no specific detection commands are provided in the resources.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to update the OpenEXR library to a patched version where this vulnerability is fixed.
- Upgrade OpenEXR to version 3.2.9, 3.3.11, or 3.4.11 or later, as these versions include the fix that rejects invalid variable-length integer encodings and enforces stricter validation on compressed string lists.
If immediate upgrade is not possible, consider restricting or monitoring the processing of untrusted EXR files, especially those containing the IDManifest attribute, to reduce the risk of exploitation.