ghsa-h45x-qhg2-q375
Vulnerability from github
8.4 (High) - CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
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:
```cpp
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
:
```cpp 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
exrcheck
binary in a macOS or GNU/Linux machine with ASAN. - Open the
heap_overflow.exr
file with the following command:
exrcheck heap_overflow.exr
- Notice that
exrcheck
crashes 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": [ { "package": { "ecosystem": "PyPI", "name": "OpenEXR" }, "ranges": [ { "events": [ { "introduced": "3.3.0" }, { "fixed": "3.3.3" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2025-48071" ], "database_specific": { "cwe_ids": [ "CWE-122" ], "github_reviewed": true, "github_reviewed_at": "2025-07-31T19:12:56Z", "nvd_published_at": "2025-07-31T21:15:27Z", "severity": "HIGH" }, "details": "### Summary\n\nThe 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.\n\n### Details\nWhen 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:\n\n```cpp\n\nif (part-\u003estorage_mode == EXR_STORAGE_DEEP_SCANLINE)\n// SNIP...\n cinfo-\u003esample_count_data_offset = dataoff;\n cinfo-\u003esample_count_table_size = (uint64_t) ddata[0];\n cinfo-\u003edata_offset = dataoff + (uint64_t) ddata[0];\n cinfo-\u003epacked_size = (uint64_t) ddata[1];\n cinfo-\u003eunpacked_size = (uint64_t) ddata[2];\n// SNIP...\n```\n\nBy storing this information, the code that will later decompress and reconstruct the chunk bytes, will know how much space the uncompressed data will occupy.\n\nThis size is carried along in the chain of decoding/decompression until the `undo_zip_impl` function in `src/lib/OpenEXRCore/internal_zip.c`:\n\n```cpp\nstatic exr_result_t\nundo_zip_impl (\n exr_decode_pipeline_t* decode,\n const void* compressed_data,\n uint64_t comp_buf_size,\n void* uncompressed_data,\n uint64_t uncompressed_size,\n void* scratch_data,\n uint64_t scratch_size)\n{\n size_t actual_out_bytes;\n exr_result_t res;\n\n if (scratch_size \u003c uncompressed_size) return EXR_ERR_INVALID_ARGUMENT;\n\n res = exr_uncompress_buffer (\n decode-\u003econtext,\n compressed_data,\n comp_buf_size,\n scratch_data,\n scratch_size,\n \u0026actual_out_bytes);\n\n if (res == EXR_ERR_SUCCESS)\n {\n decode-\u003ebytes_decompressed = actual_out_bytes;\n if (comp_buf_size \u003e actual_out_bytes)\n res = EXR_ERR_CORRUPT_CHUNK;\n else\n internal_zip_reconstruct_bytes (\n uncompressed_data, scratch_data, actual_out_bytes);\n }\n\n return res;\n}\n```\n\nThe `uncompressed_size`\u00a0comes from the `unpacked_size`\u00a0extracted earlier, and the `uncompressed_data` is a buffer allocated by making space for the size \"advertised\" in the chunk information.\n\nHowever, `scratch_data` and `actual_out_bytes` will contain, after decompression, the uncompressed data and its size, respectively. \n\nThe vulnerability lies in the fact that the `undo_zip_impl` function lacks code to check whether `actual_out_bytes` is greater than `uncompressed_size`. \n\nThe 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.\n\n### PoC\n\nNOTE: you can download the `heap_overflow.exr` file from this link:\n\nhttps://github.com/ShielderSec/poc/tree/main/CVE-2025-48071\n\n1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN.\n2. Open the `heap_overflow.exr` file with the following command:\n\n```\nexrcheck heap_overflow.exr\n```\n\n3. Notice that `exrcheck` crashes with an ASAN stack-trace.\n\n\n### Impact\n\nAn 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.", "id": "GHSA-h45x-qhg2-q375", "modified": "2025-08-13T21:37:55Z", "published": "2025-07-31T19:12:56Z", "references": [ { "type": "WEB", "url": "https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-h45x-qhg2-q375" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48071" }, { "type": "WEB", "url": "https://github.com/AcademySoftwareFoundation/openexr/commit/916cc729e24aa16b86d82813f6e136340ab2876f" }, { "type": "PACKAGE", "url": "https://github.com/AcademySoftwareFoundation/openexr" }, { "type": "WEB", "url": "https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.3.3" }, { "type": "WEB", "url": "https://github.com/ShielderSec/poc/tree/main/CVE-2025-48071" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "type": "CVSS_V3" }, { "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N", "type": "CVSS_V4" } ], "summary": "OpenEXR Heap-Based Buffer Overflow in Deep Scanline Parsing via Forged Unpacked Size" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.