CVE-2026-39886
Signed Integer Overflow in OpenEXR HTJ2K Decompression Causes Heap Corruption
Publication date: 2026-04-21
Last updated on: 2026-04-22
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openexr | openexr | From 3.4.0 (inc) to 3.4.10 (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
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade OpenEXR to version 3.4.10 or later, which contains the fix for this vulnerability.
The fix involves changing the bytes-per-line accumulator variable from a 32-bit signed integer to a 64-bit signed integer and adding overflow checks to prevent the integer overflow.
Until the upgrade can be applied, avoid processing untrusted or crafted EXR files with extremely high channel counts and maximum width values that could trigger the overflow.
If possible, implement file validation or filtering to reject EXR files with suspiciously large numbers of channels or dimensions.
Can you explain this vulnerability to me?
CVE-2026-39886 is a signed 32-bit integer overflow vulnerability in the OpenEXR library's HTJ2K decompression path, specifically in the function ht_undo_impl() within internal_ht.cpp.
The vulnerability occurs because a 32-bit signed integer variable (bpl) is used to accumulate a bytes-per-line value without any overflow checks. When processing a specially crafted EXR file with an extremely high number of FLOAT channels (16,385) at the maximum width (32,767), the calculation of bpl exceeds the maximum value for a signed 32-bit integer (INT_MAX), causing it to overflow and wrap to a negative value.
This overflow leads to undefined behavior confirmed by runtime checks, and on systems with permissive memory allocators where a large buffer allocation (~64 GB) succeeds, the negative bpl value is used as a pointer offset, potentially causing a heap out-of-bounds write.
On memory-constrained systems, the allocation fails before the vulnerable code is reached, causing an out-of-memory abort, which is not considered a security vulnerability by OpenEXR policy.
The vulnerability is distinct from a previously fixed integer overflow in the same function and requires a fix that changes the bpl variable to a 64-bit integer and adds overflow guards.
How can this vulnerability impact me? :
If exploited, this vulnerability can cause heap out-of-bounds writes during the decompression of crafted EXR files with extremely high channel counts and maximum width.
Such out-of-bounds writes can lead to memory corruption, application crashes, or potentially other undefined behaviors depending on the host environment.
However, exploitation requires a host system with permissive memory allocation that allows a very large (~64 GB) buffer allocation to succeed.
On systems with limited memory, the vulnerability results in an out-of-memory abort before the vulnerable code is executed, which is not considered a security risk.
Overall, the impact ranges from denial of service (crashes) to potential memory corruption, with a CVSS base score of 5.3 (medium) under typical conditions and up to 7.3 (high) if the out-of-bounds write occurs.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by analyzing EXR files for unusually high channel counts and maximum width values that trigger the signed integer overflow in the OpenEXR HTJ2K decompression path.
Specifically, crafted EXR files with 16,385 FLOAT channels at the HTJ2K maximum width of 32,767 cause the overflow.
A practical detection method is to run the OpenEXR utility `exrcheck` with the `-c` option on suspicious EXR files, which attempts to decompress and validate the file.
For example, the command:
- exrcheck -c suspicious_file.exr
can be used to detect problematic files. Note that on memory-constrained hosts, this may cause an out-of-memory abort before reaching the vulnerable code.
Additionally, running a UBSan-enabled harness such as `harness_bpl_overflow.cpp` can confirm the presence of the signed integer overflow during decompression.
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.