CVE-2026-34543: OpenEXR Information Disclosure Flaw

CVE-2026-34543 Overview

CVE-2026-34543 is an information disclosure vulnerability in OpenEXR, the specification and reference implementation of the EXR file format widely used in the motion picture industry for high dynamic range imaging. The vulnerability affects versions 3.4.0 through 3.4.7, where sensitive information from heap memory may be leaked through decoded pixel data when processing maliciously crafted EXR files.

Critical Impact

This vulnerability enables attackers to extract sensitive heap memory contents simply by tricking a user or application into processing a malicious EXR image file, potentially exposing confidential data from the application's memory space.

Affected Products

• OpenEXR versions 3.4.0 through 3.4.7
• Applications and libraries utilizing vulnerable OpenEXR versions for EXR file processing
• Media production software and pipelines incorporating the affected OpenEXR library

Discovery Timeline

• 2026-04-01 - CVE-2026-34543 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-34543

Vulnerability Analysis

This vulnerability stems from CWE-908: Use of Uninitialized Resource, specifically affecting the PXR24 decompression routine in OpenEXR's core library. The flaw occurs in the decompression pipeline when handling zlib output that does not properly match the expected packed payload size.

Under default library settings, simply reading a malicious EXR file is sufficient to trigger the information disclosure without requiring any additional user interaction. The vulnerability allows attackers to craft specially designed EXR files that, when processed, cause the library to include uninitialized heap memory contents in the decoded pixel data output.

Root Cause

The root cause lies in inadequate validation of decompressed data size in the PXR24 compression handler. When LIBDEFLATE_SHORT_OUTPUT was returned during decompression, the code previously lacked proper size verification, allowing decompressed output that didn't match the expected payload size to be accepted without proper bounds checking. This resulted in uninitialized memory being exposed through the decoded pixel buffer.

Attack Vector

An attacker can exploit this vulnerability by crafting a malicious EXR file with manipulated compression metadata. When a vulnerable application processes this file:

1. The malformed EXR triggers the PXR24 decompression path
2. The decompression produces output with size mismatches against the expected payload
3. The application reads beyond intended buffer boundaries into uninitialized heap memory
4. Sensitive heap data is exposed through the decoded pixel output

The attack requires network delivery of the malicious file (email attachment, web download, cloud storage) but no additional user interaction beyond opening the file.

// Vulnerable code path - inadequate size validation
// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/5f6d0aaa9e43802917af7db90f181e88e083d3b8

         }
         else if (res == LIBDEFLATE_SHORT_OUTPUT)
         {
-            /* TODO: is this an error? */
+            /* Decompression succeeded; *actual_out is the byte count. This is
+             * not an error when out_bytes_avail exceeds the true uncompressed
+             * size (e.g. PXR24/ZIP use padded scratch buffers). Callers that
+             * need an exact payload size must compare *actual_out (see e.g.
+             * undo_pxr24_impl). */
             return EXR_ERR_SUCCESS;
         }
         return EXR_ERR_CORRUPT_CHUNK;

The patch also addresses bounds checking in the PXR24 implementation:

// Fixed bounds checking in internal_pxr24.c
// Source: https://github.com/AcademySoftwareFoundation/openexr/commit/5f6d0aaa9e43802917af7db90f181e88e083d3b8

                     ptr[3] = lastIn;
                     lastIn += w;

-                    if (nDec + nBytes > uncompressed_size)
+                    if (nDec + nBytes > outSize)
                         return EXR_ERR_CORRUPT_CHUNK;

                     for (int x = 0; x < w; ++x)

Detection Methods for CVE-2026-34543

Indicators of Compromise

• Unexpected EXR files appearing in ingest directories or email attachments
• Applications processing EXR files that crash or produce corrupted output with unusual pixel artifacts
• Memory analysis showing uninitialized heap patterns in decoded image buffers
• Network traffic containing EXR files from untrusted or unexpected sources

Detection Strategies

• Monitor applications using OpenEXR library for abnormal memory access patterns during EXR file processing
• Implement file integrity checks for EXR files entering production pipelines from external sources
• Deploy endpoint detection rules to identify processes loading vulnerable OpenEXR library versions (3.4.0 through 3.4.7)
• Enable heap memory sanitizers in development and testing environments to detect uninitialized memory reads

Monitoring Recommendations

• Audit all systems and applications for installed OpenEXR library versions to identify vulnerable deployments
• Monitor media production pipelines for EXR files originating from untrusted external sources
• Implement logging for EXR file processing operations to aid in forensic analysis if exploitation occurs
• Track library dependency updates across CI/CD pipelines to ensure timely patching

How to Mitigate CVE-2026-34543

Immediate Actions Required

• Upgrade OpenEXR to version 3.4.8 or later immediately on all affected systems
• Audit all applications and dependencies that incorporate OpenEXR library for vulnerable versions
• Restrict processing of EXR files from untrusted sources until patching is complete
• Review recent EXR file processing logs for any anomalous behavior indicating potential exploitation

Patch Information

The vulnerability has been patched in OpenEXR version 3.4.8. The fix implements proper validation of zlib decompression output against expected payload sizes in the PXR24 compression handler. The patch is available via:

• GitHub Release v3.4.8
• Security Advisory GHSA-vc68-257w-m432
• Commit 5f6d0aa

Workarounds

• Avoid processing EXR files from untrusted or unknown sources until the patch can be applied
• Implement network-level filtering to quarantine incoming EXR files for scanning before allowing access to production systems
• Consider sandboxing applications that process EXR files to limit potential information exposure
• Disable PXR24 compression support temporarily if application allows configuration of supported compression methods

# Configuration example
# Verify OpenEXR version and upgrade if vulnerable
pkg-config --modversion OpenEXR
# If version is between 3.4.0 and 3.4.7, upgrade immediately

# For systems using package managers:
# Debian/Ubuntu
sudo apt update && sudo apt install openexr

# Fedora/RHEL
sudo dnf update openexr

# macOS with Homebrew
brew upgrade openexr

# Verify updated version
pkg-config --modversion OpenEXR
# Should report 3.4.8 or later