CVE-2025-48071: OpenEXR Buffer Overflow Vulnerability

CVE-2025-48071 Overview

CVE-2025-48071 is a heap-based buffer overflow [CWE-122] in OpenEXR, the reference implementation of the EXR image file format widely used in motion picture production. The flaw exists in the decompression routine for ZIPS-packed deep scan-line EXR files. A maliciously forged chunk header triggers an out-of-bounds write during the decompression operation. OpenEXR versions 3.3.0 through 3.3.2 are affected, and the issue is fixed in version 3.3.3.

Critical Impact

Processing a crafted EXR file can corrupt heap memory in any application that links the OpenEXR library, enabling potential code execution in image rendering, compositing, and pipeline tooling.

Affected Products

• OpenEXR 3.3.0
• OpenEXR 3.3.1
• OpenEXR 3.3.2

Discovery Timeline

• 2025-07-31 - CVE-2025-48071 published to NVD
• 2025-08-13 - Last updated in NVD database

Technical Details for CVE-2025-48071

Vulnerability Analysis

The vulnerability resides in the OpenEXR core decompression path for ZIPS-packed deep scan-line chunks. OpenEXR uses chunk headers to describe the compressed and uncompressed sizes of pixel data. When the library decompresses a ZIPS-packed deep scan-line chunk, it trusts the actual output byte count returned by zlib without validating it against the declared uncompressed buffer size. An attacker who supplies a crafted chunk header causes zlib to produce more bytes than the destination buffer can hold. The result is a heap write past the allocated region in internal_zip_reconstruct_bytes processing.

Root Cause

The root cause is a missing upper-bound check in src/lib/OpenEXRCore/internal_zip.c. Prior to the fix, the code verified only that comp_buf_size > actual_out_bytes. It did not verify that actual_out_bytes was within the allocated uncompressed_size. Forging the header lets the decoder accept a larger-than-expected output and overwrite adjacent heap memory.

Attack Vector

Exploitation requires the victim to open or process a malicious .exr file using a vulnerable OpenEXR build. Typical attack surfaces include visual effects pipelines, render farms, image viewers, game engines, and content-creation tools that embed OpenEXR. User interaction is required, but the file can be delivered through email, shared storage, asset repositories, or supply-chain assets.

     if (res == EXR_ERR_SUCCESS)
     {
         decode->bytes_decompressed = actual_out_bytes;
-        if (comp_buf_size > actual_out_bytes)
+        if (comp_buf_size > actual_out_bytes || actual_out_bytes > uncompressed_size)
             res = EXR_ERR_CORRUPT_CHUNK;
         else
             internal_zip_reconstruct_bytes (

Source: OpenEXR commit 916cc729 — the patch adds the missing actual_out_bytes > uncompressed_size check and returns EXR_ERR_CORRUPT_CHUNK when a forged header is detected.

Detection Methods for CVE-2025-48071

Indicators of Compromise

• EXR files where the chunk header declared sizes do not match the actual ZIPS payload after decompression.
• Crashes or heap corruption reports in processes that load OpenEXR, such as compositors, renderers, and image viewers.
• Unexpected child processes or shell activity spawned by image-processing applications shortly after opening an .exr asset.

Detection Strategies

• Inventory all software using openexr 3.3.0 through 3.3.2 via software composition analysis tools and package managers.
• Inspect EXR ingestion points for deep scan-line files compressed with ZIPS and validate header integrity before processing.
• Hunt for process crash telemetry referencing libOpenEXR, OpenEXRCore, or internal_zip_reconstruct_bytes frames.

Monitoring Recommendations

• Monitor file shares, asset management systems, and render queues for newly introduced .exr files from untrusted sources.
• Alert on abnormal memory faults or watchdog restarts in DCC (digital content creation) and rendering services.
• Track OpenEXR library versions across build pipelines and container images to detect regressions to vulnerable releases.

How to Mitigate CVE-2025-48071

Immediate Actions Required

• Upgrade OpenEXR to version 3.3.3 or later in all production and developer environments.
• Rebuild and redistribute any internal tools that statically link OpenEXR against the patched release.
• Restrict ingestion of EXR files from untrusted external sources until upgrades are verified.

Patch Information

The fix is included in OpenEXR v3.3.3. See the GitHub Security Advisory GHSA-h45x-qhg2-q375 and the OpenEXR v3.3.3 release notes for full details. The patch adds bounds validation in internal_zip.c so decompressed output exceeding the declared uncompressed size returns EXR_ERR_CORRUPT_CHUNK.

Workarounds

• If immediate patching is not feasible, block processing of deep scan-line EXR files that use ZIPS compression at ingestion gateways.
• Process untrusted EXR files only inside sandboxed or containerized environments with strict resource and syscall limits.
• Apply file integrity controls and source-of-origin checks for assets entering render pipelines.

# Verify installed OpenEXR version on Linux systems
pkg-config --modversion OpenEXR

# Upgrade via package manager examples
apt-get update && apt-get install --only-upgrade libopenexr-3-1-30
brew upgrade openexr

# Python bindings
pip install --upgrade 'openexr>=3.3.3'