CVE-2026-34589
Integer Overflow in OpenEXR DWA Decoder Causes Out-of-Bounds Access
Publication date: 2026-04-06
Last updated on: 2026-04-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openexr | openexr | From 3.2.0 (inc) to 3.2.7 (exc) |
| openexr | openexr | From 3.3.0 (inc) to 3.3.9 (exc) |
| openexr | openexr | From 3.4.0 (inc) to 3.4.9 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-787 | The product writes data past the end, or before the beginning, of the intended buffer. |
| 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
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of CVE-2026-34589 on compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
CVE-2026-34589 is a high-severity vulnerability in the OpenEXR library's DWA lossy decoder affecting versions 3.2.0 through 3.2.6, 3.3.0 through 3.3.8, and 3.4.0 through 3.4.8. The issue arises from an integer overflow during the construction of temporary per-component block pointers using signed 32-bit arithmetic.
Specifically, when the width (numBlocksX) is large enough, the multiplication numBlocksX * 64 overflows as a signed integer, causing pointer arithmetic to wrap around. This results in pointers pointing outside the allocated buffer backwards instead of forwards.
This corrupted pointer is then used during the block shuffle and reconstruction phase in the LossyDctDecoder_execute() function, leading to out-of-bounds writes on the heap and causing a crash (segmentation fault).
The vulnerability can be triggered by a specially crafted scanline DWAA file and requires user interaction to initiate decoding.
How can this vulnerability impact me? :
This vulnerability can cause a write-side crash (segmentation fault) during decoding of specially crafted OpenEXR files, potentially leading to denial of service on the affected system.
The impact on confidentiality, integrity, and availability is rated as high on the vulnerable system, meaning it can disrupt normal operation and cause instability.
However, there is no indication of further system compromise beyond the crash, and the attack requires local access and user interaction to trigger.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by analyzing the behavior of the OpenEXR DWA lossy decoder when processing specially crafted scanline DWAA files. Dynamic analysis tools such as UBSan (Undefined Behavior Sanitizer) can identify the signed integer overflow, while ASAN (AddressSanitizer) can detect the resulting segmentation fault caused by out-of-bounds writes.
The shipped tool `exrcheck` can be used to trigger and verify the vulnerability by attempting to decode a maliciously crafted EXR file.
Suggested commands include running the `exrcheck` tool on suspicious or untrusted EXR files and using sanitizers during testing or debugging:
- Run exrcheck on a file: `exrcheck suspicious_file.exr`
- Compile OpenEXR with UBSan and run the decoder to detect integer overflow.
- Compile OpenEXR with ASAN and run the decoder to detect out-of-bounds writes and segmentation faults.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the OpenEXR library to a fixed version. The vulnerability is resolved in versions 3.2.7, 3.3.9, and 3.4.9.
Avoid processing untrusted or specially crafted EXR files with vulnerable versions of the library, as the exploit requires user-initiated decoding.
If upgrading immediately is not possible, consider running the decoder in a sandboxed or restricted environment to limit potential impact from crashes or exploitation.