Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
PYSEC-2026-1747
No affected components available
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 STORAGE_DEEP_SCANLINE chunks from an EXR file, the following code (from src/lib/OpenEXRCore/chunk.c) is used to extract the chunk information:
if (part->storage_mode == EXR_STORAGE_DEEP_SCANLINE)
// SNIP...
cinfo->sample_count_data_offset = dataoff;
cinfo->sample_count_table_size = (uint64_t) ddata[0];
cinfo->data_offset = dataoff + (uint64_t) ddata[0];
cinfo->packed_size = (uint64_t) ddata[1];
cinfo->unpacked_size = (uint64_t) 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 undo_zip_impl function in src/lib/OpenEXRCore/internal_zip.c:
static exr_result_t
undo_zip_impl (
exr_decode_pipeline_t* decode,
const void* compressed_data,
uint64_t comp_buf_size,
void* uncompressed_data,
uint64_t uncompressed_size,
void* scratch_data,
uint64_t scratch_size)
{
size_t actual_out_bytes;
exr_result_t res;
if (scratch_size < uncompressed_size) return EXR_ERR_INVALID_ARGUMENT;
res = exr_uncompress_buffer (
decode->context,
compressed_data,
comp_buf_size,
scratch_data,
scratch_size,
&actual_out_bytes);
if (res == EXR_ERR_SUCCESS)
{
decode->bytes_decompressed = actual_out_bytes;
if (comp_buf_size > actual_out_bytes)
res = EXR_ERR_CORRUPT_CHUNK;
else
internal_zip_reconstruct_bytes (
uncompressed_data, scratch_data, actual_out_bytes);
}
return res;
}
The uncompressed_size comes from the unpacked_size extracted earlier, and the uncompressed_data is a buffer allocated by making space for the size "advertised" in the chunk information.
However, scratch_data and actual_out_bytes will contain, after decompression, the uncompressed data and its size, respectively.
The vulnerability lies in the fact that the undo_zip_impl function lacks code to check whether actual_out_bytes is greater than uncompressed_size.
The effect is that, by setting the unpacked_size in the chunk header smaller than the actual chunk decompressed data, it is possible - in the internal_zip_reconstruct_bytes function - to overflow past the boundaries of a heap chunk.
PoC
NOTE: you can download the heap_overflow.exr file from this link:
https://github.com/ShielderSec/poc/tree/main/CVE-2025-48071
- Compile the
exrcheckbinary in a macOS or GNU/Linux machine with ASAN. - Open the
heap_overflow.exrfile with the following command:
exrcheck heap_overflow.exr
- Notice that
exrcheckcrashes with an ASAN stack-trace.
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.
The vulnerability requires local access to the device to be exploited. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. The attacker needs the user to perform some action, like clicking a link. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a high impact on the availability of the system.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard