CVE-2026-34380
Signed Integer Overflow in OpenEXR Causes Buffer Overflow Risk
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 this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
CVE-2026-34380 is a signed integer overflow vulnerability in the OpenEXR library, specifically in the function undo_pxr24_impl() in the file internal_pxr24.c. The issue occurs because the expression (uint64_t)(w * 3) multiplies w by 3 as a signed 32-bit integer before casting to a 64-bit unsigned integer. When w is very large, this multiplication overflows the signed 32-bit integer range, causing undefined behavior.
On typical systems using two's-complement representation and compilers like clang or gcc without sanitizers, this overflow causes wraparound, resulting in a small positive integer instead of the correct large value. This incorrect value can pass a bounds check that is supposed to prevent buffer overflows.
If the bounds check is bypassed, the decoding loop writes pixel data beyond the allocated output buffer, potentially causing out-of-bounds heap writes. This can lead to crashes or, theoretically, heap corruption and code execution.
The vulnerability affects OpenEXR versions from 3.2.0 up to but not including 3.2.7, 3.3.9, and 3.4.9, where it has been fixed by changing the multiplication to be done in 64-bit arithmetic.
How can this vulnerability impact me? :
This vulnerability can impact you by causing a denial of service (DoS) through application crashes when processing specially crafted EXR files using PXR24 compression.
More seriously, it can lead to out-of-bounds heap writes, which may corrupt memory and potentially allow an attacker to execute arbitrary code, depending on the memory allocator and layout.
The vulnerability affects any application that decodes untrusted PXR24-compressed EXR files, so if your software processes such files, it could be at risk.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for runtime errors related to signed integer overflow in the OpenEXR library, specifically in the undo_pxr24_impl() function. Using sanitizers such as UndefinedBehaviorSanitizer (UBSan) during testing or runtime can reveal signed integer overflow issues.
A proof-of-concept (PoC) is available for version 3.4.7 that demonstrates a crash when sanitizers are enabled, which can be used to verify if a system is vulnerable.
To detect the vulnerability on your system, you can run OpenEXR decoding commands with UBSan enabled or use debugging tools to check for signed integer overflow errors during the processing of PXR24-compressed EXR files.
- Compile OpenEXR with UndefinedBehaviorSanitizer (UBSan) enabled and run the decoding process on suspicious EXR files.
- Use debugging tools like gdb to trace execution around src/lib/OpenEXRCore/internal_pxr24.c at line 377.
- Monitor application logs for crashes or errors related to integer overflow or memory corruption when processing EXR files.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade OpenEXR to a fixed version where the vulnerability is patched. The vulnerability is fixed in OpenEXR versions 3.2.7, 3.3.9, and 3.4.9.
If upgrading is not immediately possible, avoid processing untrusted or potentially malicious PXR24-compressed EXR files, especially those with FLOAT pixel types and crafted dataWindow values that could trigger the overflow.
Additionally, running OpenEXR with sanitizers enabled in testing environments can help detect exploitation attempts.