CVE-2026-26981
Heap Buffer Overflow in OpenEXR `istream_nonparallel_read` Parsing Malformed EXR
Publication date: 2026-02-24
Last updated on: 2026-02-25
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openexr | openexr | From 3.3.0 (inc) to 3.3.7 (exc) |
| openexr | openexr | From 3.4.0 (inc) to 3.4.5 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-195 | The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-26981 is a heap-buffer-overflow vulnerability in the OpenEXR library, specifically in the istream_nonparallel_read function within ImfContextInit.cpp. It occurs when parsing a malformed EXR file using a memory-mapped IStream. The root cause is a signed integer underflow during a subtraction operation where a negative value is implicitly converted to an unsigned size_t type, resulting in a very large size being passed to memcpy. This leads to an out-of-bounds read (heap-buffer-overflow).
Affected versions include OpenEXR 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4. The issue is fixed in versions 3.3.7 and 3.4.5 by correcting the size calculation to avoid the signed underflow.
How can this vulnerability impact me? :
This vulnerability can cause a denial-of-service (DoS) condition by crashing any application that opens a maliciously crafted EXR file. The heap-buffer-overflow triggered by the incorrect size calculation leads to an out-of-bounds read, which can cause the application to crash immediately.
The CVSS v3.1 base score is 6.5 (Moderate), indicating a significant impact on availability but no impact on confidentiality or integrity.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crashes or denial-of-service conditions in applications that process EXR files using the OpenEXR library versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4.
Specifically, running a proof-of-concept exploit with AddressSanitizer (ASAN) enabled can reveal the heap-buffer-overflow by causing a crash due to a negative size parameter passed to memcpy.
To detect attempts to exploit this vulnerability on your system, you can monitor application logs for crashes or abnormal terminations when opening EXR files.
There are no explicit commands provided in the resources, but you can use tools like:
- AddressSanitizer (ASAN) to run vulnerable applications and detect memory errors.
- System monitoring commands such as `dmesg`, `journalctl`, or application-specific logs to identify crashes.
- Network monitoring tools to detect transfer of malformed EXR files if applicable.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the OpenEXR library to a fixed version.
- Upgrade to OpenEXR version 3.3.7 or later, or 3.4.5 or later, where the vulnerability has been patched.
If upgrading is not immediately possible, avoid processing untrusted or malformed EXR files that could trigger the vulnerability.
Additionally, consider running applications that use OpenEXR with memory error detection tools such as AddressSanitizer to detect exploitation attempts.