CVE-2026-34543: Heap Information Disclosure in OpenEXR PXR24 Decompression

CVE-2026-34543 identifies a critical heap information disclosure flaw within the OpenEXR project, a widely adopted image format standard maintained by the Academy Software Foundation. The vulnerability specifically affects the OpenEXRCore library, targeting the PXR24 decompression logic handled by the undo_pxr24_impl function. Systems utilizing OpenEXR versions 3.4.0 through 3.4.7 are susceptible to this flaw.

The vulnerability is classified under CWE-908 (Use of Uninitialized Resource). It manifests when the application processes a maliciously structured EXR file containing a truncated zlib stream. A failure in length validation causes the internal decompression routines to read beyond the initialized boundary of the decompression buffer, accessing residual heap memory left behind by previous application operations.

Exploitation of this vulnerability results in the direct leakage of sensitive heap memory contents into the output image's pixel data. The attack requires zero privileges and no user interaction beyond the target system processing the malicious file. This makes automated processing pipelines, such as cloud rendering services and media ingestion endpoints, highly vulnerable to remote exploitation.

The underlying vulnerability results from a two-part logical failure in how OpenEXR handles mismatched buffer sizes during decompression. The process begins in src/lib/OpenEXRCore/compression.c, where the exr_uncompress_buffer function delegates the decompression task to the libdeflate library. When a truncated stream is processed, libdeflate correctly identifies the state and returns the LIBDEFLATE_SHORT_OUTPUT status code.

The first point of failure occurs because exr_uncompress_buffer incorrectly interprets LIBDEFLATE_SHORT_OUTPUT as a fully successful operation. The function returns EXR_ERR_SUCCESS to the calling routine without properly validating whether the produced output size aligns with the caller's allocation expectations. The decompression engine fails to signal the size discrepancy, passing an incompletely populated buffer to the reconstruction logic.

The second point of failure resides in the PXR24 decoder (undo_pxr24_impl in internal_pxr24.c). This function ignores the actual number of decompressed bytes written, referred to as outSize. Instead, the function relies on the uncompressed_size field provided directly by the untrusted EXR file header to drive its byte-plane reconstruction and difference decoding loops.

Because the uncompressed_size field dictates the iteration length, the loops march past the initialized data boundaries of the scratch_data buffer. The decoder processes the uninitialized heap memory following the truncated data payload, reconstructing it as valid image pixels. The resulting image file encodes chunks of raw heap data, successfully exfiltrating the memory contents.

Prior to version 3.4.8, the undo_pxr24_impl function explicitly trusted the EXR header metadata to define processing boundaries. The code checked the iteration progress against uncompressed_size, an integer entirely controlled by the file structure. This assumption proved dangerous when coupled with the upstream failure to reject truncated zlib streams.

The patch applied in commit 5f6d0aaa9e43802917af7db90f181e88e083d3b8 corrects the iteration bounds check. The relevant modification occurs in src/lib/OpenEXRCore/internal_pxr24.c. The comparison operator now evaluates the processing index against outSize, which represents the actual byte count returned by the decompression engine.

// Snippet from src/lib/OpenEXRCore/internal_pxr24.c
- if (nDec + nBytes > uncompressed_size)
+ if (nDec + nBytes > outSize)
      return EXR_ERR_CORRUPT_CHUNK;

This modification fundamentally alters the trust model within the function. By constraining the iteration bounds to the validated, physical size of the decompressed buffer rather than arbitrary file metadata, the loops correctly terminate before crossing into uninitialized heap space. The function returns an EXR_ERR_CORRUPT_CHUNK error upon encountering mismatched stream limits, preventing the CWE-908 condition entirely.

Exploiting CVE-2026-34543 requires the attacker to deliver a carefully constructed EXR file to the target system. The payload targets the PXR24 compression scheme specifically. The attacker manually configures the EXR header, assigning an artificially large value to the uncompressed_size metadata field while attaching a compressed data payload that is structurally valid but deliberately truncated.

When the vulnerable application processes the file, the large uncompressed_size value dictates the initial allocation of the internal decoding buffer. The libdeflate routine processes the truncated zlib stream, populating only the beginning of the allocated buffer. The remaining space within the buffer consists of residual heap memory from previously executed application tasks.

The target application completes the decoding process without throwing a fatal exception. The uninitialized heap bytes are subjected to the PXR24 byte-plane reconstruction algorithms and stored within the final pixel array. The attacker completes the exploitation sequence by retrieving the resulting output image, either through a direct download feature or by capturing the visual output, and reversing the PXR24 encoding to read the raw heap memory.

The primary impact of CVE-2026-34543 is a severe breach of confidentiality. Applications that process untrusted media files, such as rendering farms, image hosting platforms, and content delivery networks, run a high risk of exposing internal process memory. The leaked memory frequently contains sensitive application state data, including API keys, authentication tokens, TLS private keys, or data belonging to other tenants in a shared environment.

The vulnerability is scored at 8.7 (High) under the CVSSv4 framework. The vector string (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) reflects the complete absence of prerequisites. An unauthenticated attacker can launch the attack over the network with low complexity, requiring no user interaction. The high confidentiality impact score accurately captures the severity of process memory exposure.

Despite the severity, the Exploit Prediction Scoring System (EPSS) rating currently sits at 0.04% (12.21st percentile). This low probability indicates that active exploitation in the wild remains unlikely in the near term. Furthermore, the vulnerability only affects the confidentiality of the system; an attacker cannot alter application behavior or cause a denial of service through this specific code path.

The most definitive remediation for CVE-2026-34543 is updating the OpenEXR library to version 3.4.8 or later. Organizations must audit their dependency trees to identify both dynamic and static linkages to libOpenEXRCore. Applications utilizing static linking require recompilation with the updated library to eliminate the vulnerable code path completely.

For systems where immediate patching is unfeasible, administrators should implement defensive strategies around the image ingestion pipeline. Isolating the image processing workloads within short-lived, sandboxed containers significantly limits the value of the exposed heap memory. A fresh container allocation ensures the heap does not contain long-lived secrets or residual data from prior operations belonging to other users.

Additionally, security teams can implement structural validation checks prior to passing files to the OpenEXR parser. Rejecting EXR files that exhibit extreme disparities between declared metadata sizes and physical byte counts can disrupt the exploitation sequence. However, this approach carries a high risk of false positives and may break compatibility with legitimate, highly compressed media files.