GHSA-h45x-qhg2-q375
HIGHOpenEXR Heap-Based Buffer Overflow in Deep Scanline Parsing via Forged Unpacked Size
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
openexrReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | openexr | ≥ 3.3.0&&< 3.3.3 | 3.3.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openexr. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update openexr to 3.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h45x-qhg2-q375 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-h45x-qhg2-q375 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h45x-qhg2-q375. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h45x-qhg2-q375 in your dependencies?
O3 detects GHSA-h45x-qhg2-q375 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.