GHSA-H45X-QHG2-Q375

Vulnerability from github – Published: 2025-07-31 19:12 – Updated: 2025-08-13 21:37
VLAI
Summary
OpenEXR Heap-Based Buffer Overflow in Deep Scanline Parsing via Forged Unpacked Size
Details

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

  1. Compile the exrcheck binary in a macOS or GNU/Linux machine with ASAN.
  2. Open the heap_overflow.exr file with the following command:
exrcheck heap_overflow.exr
  1. 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.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
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
Show details on source website
To clipboard 

{
  "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![image](https://github.com/user-attachments/assets/57907073-bc9f-40bb-9030-16008035ade8)\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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.