CVE-2026-41142
BaseFortify
Publication date: 2026-05-07
Last updated on: 2026-05-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| academysoftwarefoundation | openexr | From 3.0.0 (inc) to 3.2.9 (exc) |
| academysoftwarefoundation | openexr | From 3.3.0 (inc) to 3.3.11 (exc) |
| academysoftwarefoundation | openexr | From 3.4.0 (inc) to 3.4.11 (exc) |
| academysoftwarefoundation | openexr | 3.2.9 |
| academysoftwarefoundation | openexr | 3.3.11 |
| academysoftwarefoundation | openexr | 3.4.11 |
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-41142 is an integer overflow vulnerability in the OpenEXR library's ImageChannel::resize function. When resizing images, the calculation of the total pixel count (width multiplied by height) can overflow a signed integer, causing the program to allocate less memory than needed. This leads to heap out-of-bounds write operations when the program writes pixel data beyond the allocated buffer.
The vulnerability affects multiple OpenEXR versions from 3.0.0 up to but not including 3.2.9, 3.3.0 up to but not including 3.3.11, and 3.4.0 up to but not including 3.4.11. The issue was fixed by changing the pixel count calculation to use a 64-bit unsigned integer and adding validation to reject invalid or excessively large image dimensions and zero sampling values.
How can this vulnerability impact me? :
This vulnerability can lead to heap buffer overflows, allowing an attacker to write arbitrary data to memory locations outside the intended buffer. Because the attacker can control the content of these writes, this can potentially result in arbitrary code execution or denial of service (application crashes).
The vulnerability can be triggered remotely without requiring privileges, as it can be exploited via public APIs or by processing crafted image files. The CVSS score of 8.8 indicates a high severity with impacts on confidentiality, integrity, and availability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability is an integer overflow in the OpenEXR library's ImageChannel::resize function, which can be triggered via public APIs such as FlatImage::insertChannel() or file parsing paths like loadFlatScanLineImage. Detection would involve 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) on your system.
To detect vulnerable versions, you can check the installed OpenEXR package version using commands like:
- On Linux systems with package managers: `dpkg -l | grep openexr` or `rpm -qa | grep openexr`
- If OpenEXR is built from source or included in software, check the version via the software's version command or inspect the library files.
Additionally, monitoring for suspicious or malformed EXR files that trigger the vulnerability via the OpenEXRUtil public API could be done by logging or tracing calls to functions like FlatImage::insertChannel() or loadFlatScanLineImage in your application, though no specific detection commands are provided.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade the OpenEXR library to a patched version where this vulnerability is fixed.
- Upgrade to OpenEXR version 3.2.9, 3.3.11, or 3.4.11 or later, as these versions contain the fix for the integer overflow in ImageChannel::resize.
If upgrading immediately is not possible, consider restricting or monitoring the use of the OpenEXRUtil public API and avoid processing untrusted or malformed EXR files that could trigger the vulnerability.
The patch includes validation of image dimensions and sampling values to prevent overflow and division by zero, so ensuring these validations are in place in your OpenEXR usage can help mitigate risk.