CVE-2026-68515 in OpenEXR
Summary
by MITRE • 08/25/2026
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, exrmultiview can write past a heap allocation when it combines two attacker-supplied, individually valid scanline EXR files whose union dataWindow is not aligned to one view's channel subsampling. The utility allocates sampled channel storage using a truncated union_width / xSampling, then reads the sampled input through a Slice based on the misaligned union window, producing a heap out-of-bounds write. The trigger is normal public-tool processing, such as exrmultiview left A.exr right B.exr out.exr with crafted but valid inputs, so this is not solely an API or caller-precondition issue. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
OpenEXR serves as the reference implementation for the EXR image format, a standard extensively utilized within the motion picture industry for high-dynamic-range imaging and visual effects workflows. The vulnerability identified in versions prior to 3.2.11, between 3.3.0 and 3.3.12, and from 3.4.0 through 3.4.13 resides specifically within the exrmultiview utility. This tool is designed to combine multiple EXR files into a single multi-view output, a common operation in stereoscopic or volumetric rendering pipelines. The flaw manifests as a heap-based buffer overflow that occurs during the processing of input files where the union data window geometry does not align correctly with the channel subsampling parameters defined by one of the views. This misalignment leads to an incorrect calculation of memory requirements for sampled channel storage, resulting in insufficient allocation and subsequent out-of-bounds writes when the utility attempts to read and process the slice data based on the miscalculated dimensions.
The technical root cause lies in how exrmultiview calculates the width of the output buffer relative to the xSampling factor. When combining two attacker-supplied but individually valid scanline EXR files, the tool computes a truncated union_width divided by xSampling for allocation purposes. However, during the actual data processing phase, it reads through a Slice based on the misaligned union window dimensions without accounting for this truncation error in the context of subsampling alignment. This discrepancy causes the utility to write past the end of the allocated heap buffer. Because the trigger involves normal public-tool usage patterns such as executing exrmultiview with crafted inputs, this is not merely an API misuse or caller-precondition issue but a fundamental logic flaw within the tool itself that can be exploited by providing specifically constructed EXR files.
From a security impact perspective, this heap out-of-bounds write allows for potential arbitrary code execution if the attacker can control the data written beyond the buffer boundary and manipulate adjacent memory structures such as function pointers or object headers. Even without full code execution, such vulnerabilities often lead to application crashes causing denial of service conditions in automated processing pipelines common in film production environments where large batches of images are processed sequentially. The vulnerability maps directly to CWE-787 Out-of-bounds Write within the Common Weakness Enumeration framework and aligns with ATT&CK technique T1203 Exploitation for Client Execution if leveraged against a user running the tool, or potentially T1496 Resource Hijacking if used primarily for denial of service.
Mitigation strategies require immediate upgrading to patched versions including 3.2.11, 3.3.13, and 3.4.14 which correct the buffer allocation logic to properly account for subsampling alignment issues during union window calculations. Organizations relying on OpenEXR tools should verify their version numbers across all systems involved in image processing workflows. Additionally, implementing strict input validation at ingestion points can provide defense-in-depth by rejecting files with suspicious or malformed geometric metadata before they reach vulnerable components until patches are fully deployed.