CVE-2025-48071: OpenEXR's Forged Unpacked Size can Lead to Heap-Based Buffer Overflow in Deep Scanline Parsing
Summary
The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header.
Details When parsing STORAGEDEEPSCANLINE chunks from an EXR file, the following code (from src/lib/OpenEXRCore/chunk.c) is used to extract the chunk information:
cpp
if (part->storagemode == EXRSTORAGEDEEPSCANLINE) // SNIP... cinfo->samplecountdataoffset = dataoff; cinfo->samplecounttablesize = (uint64t) ddata[0]; cinfo->dataoffset = dataoff + (uint64t) ddata[0]; cinfo->packedsize = (uint64t) ddata[1]; cinfo->unpackedsize = (uint64t) ddata[2]; // SNIP...
By storing this information, the code that will later decompress and reconstruct the chunk bytes, will know how much space the uncompressed data will occupy.
This size is carried along in the chain of decoding/decompression until the undozipimpl function in src/lib/OpenEXRCore/internalzip.c:
cpp static exrresultt undozipimpl ( exrdecodepipelinet decode, const void compresseddata, uint64t compbufsize, void uncompresseddata, uint64t uncompressedsize, void scratchdata, uint64t scratchsize) { sizet actualoutbytes; exrresultt res;
if (scratchsize < uncompressedsize) return EXRERRINVALIDARGUMENT;
res = exruncompressbuffer ( decode->context, compresseddata, compbufsize, scratchdata, scratchsize, &actualoutbytes);
if (res == EXRERRSUCCESS) { decode->bytesdecompressed = actualoutbytes; if (compbufsize > actualoutbytes) res = EXRERRCORRUPTCHUNK; else internalzipreconstructbytes ( uncompresseddata, scratchdata, actualoutbytes); }
return res; }
The uncompressedsize comes from the unpackedsize extracted earlier, and the uncompresseddata is a buffer allocated by making space for the size "advertised" in the chunk information.
However, scratchdata and actualoutbytes will contain, after decompression, the uncompressed data and its size, respectively.
The vulnerability lies in the fact that the undozipimpl function lacks code to check whether actualoutbytes is greater than uncompressedsize.
The effect is that, by setting the unpackedsize in the chunk header smaller than the actual chunk decompressed data, it is possible - in the internalzipreconstructbytes function - to overflow past the boundaries of a heap chunk.
PoC
NOTE: you can download the heapoverflow.exr file from this link:
https://github.com/ShielderSec/poc/tree/main/CVE-2025-48071
1. Compile the exrcheck binary in a macOS or GNU/Linux machine with ASAN. 2. Open the heapoverflow.exr file with the following command:
exrcheck heapoverflow.exr
3. Notice that exrcheck crashes with an ASAN stack-trace. !image
Impact
An attacker might exploit this vulnerability by feeding a maliciously crafted file to a program that uses the OpenEXR libraries, thus gaining the capability to write an arbitrary amount of bytes in the heap. This could potentially result in code execution in the process.
Other sources
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.2 through 3.3.0, there is a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header. This is fixed in version 3.3.3.
— MITRE
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2025-48071?
CVE-2025-48071 is classified as a high-severity vulnerability due to the potential for remote code execution through a heap-based buffer overflow.
How do I fix CVE-2025-48071?
To fix CVE-2025-48071, upgrade OpenEXR to version 3.3.3 or later.
What versions are affected by CVE-2025-48071?
CVE-2025-48071 affects OpenEXR versions from 3.3.0 up to but not including 3.3.3.
What type of vulnerability is CVE-2025-48071?
CVE-2025-48071 is a heap-based buffer overflow vulnerability affecting the handling of deep scan-line EXR files.
Can CVE-2025-48071 be exploited remotely?
Yes, CVE-2025-48071 can be exploited remotely if a user processes a maliciously crafted EXR file.