CVE-2026-63419 in OpenImageIOinfo

Summary

by MITRE • 09/18/2026

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1, A zbuffer-only tiled iff is exposed with a 16-bit public imagespec while the decoder retains a 32-bit internal pixel size. iffinput::read_native_tile() copies according to m_header.pixel_bytes() rather than imagespec::tile_bytes(true), and a failed read can leave m_buf nonempty so a later call copies partially initialized data into the undersized caller buffer, resulting in a heap out-of-bounds write and memory corruption. The affected implementation is identified by src/iff.imageio/iffinput.cpp, IffInput::read_native_tile(), ImageSpec::tile_bytes(true), m_header.pixel_bytes(), ZBUFFER, and m_buf, which define the relevant source path, functions, state, and trigger. This issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 09/18/2026

The vulnerability identified within OpenImageIO prior to versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1 represents a critical memory safety flaw rooted in the handling of Z-buffer tiled IFF image files. This issue specifically affects the decoding process where there is a discrepancy between the public interface specifications and internal data structures. When processing these specific file formats, the decoder exposes a sixteen-bit public imagespec to higher-level application logic while simultaneously retaining a thirty-two-bit internal pixel size for actual data manipulation. This architectural inconsistency creates a dangerous state where external callers operate under incorrect assumptions about memory layout and buffer sizes relative to what is actually present in memory.

The core technical flaw resides within the iffinput::read_native_tile() function located in src/iff.imageio/iffinput.cpp. During execution, this routine copies data based on m_header.pixel_bytes(), which reflects the internal thirty-two-bit depth, rather than utilizing imagespec::tile_bytes(true), which correctly calculates the size according to the public sixteen-bit specification provided by the caller. This mismatch means that when a read operation is initiated for a tile of image data, the function attempts to write more bytes into the destination buffer than was allocated or expected based on the public interface contract. The trigger condition often involves scenarios where a previous read attempt fails but leaves m_buf in a non-empty state, meaning residual uninitialized memory remains available for subsequent operations.

The operational impact of this vulnerability is severe, leading directly to heap out-of-bounds writes and general memory corruption. Because the decoder copies data according to its internal thirty-two-bit width into a buffer sized for sixteen bits, it overwrites adjacent memory regions on the heap. This overflow can corrupt critical program state, lead to application crashes through segmentation faults or access violations, and potentially allow an attacker to execute arbitrary code by manipulating the overwritten memory structures. In professional visual effects and animation pipelines where OpenImageIO is heavily utilized, such instability poses a significant risk to production integrity and data security.

This vulnerability aligns with CWE-787: Out-of-bounds Write, as it involves writing data beyond the allocated boundary of a buffer due to incorrect size calculations. From an offensive perspective, this flaw could be leveraged in attacks categorized under ATT&CK techniques related to memory corruption exploitation, potentially facilitating remote code execution if processed untrusted input is involved. The specific mechanism highlights how internal state management failures can propagate into external interface violations, emphasizing the need for strict validation of buffer sizes against actual data dimensions during decoding operations.

Mitigation strategies primarily involve upgrading OpenImageIO to version 3.0.21.0 or later, specifically including versions 3.1.16.0 and 3.2.0.3-beta1 where this issue has been resolved. Developers integrating the library should ensure that their build environments are configured to pull these patched releases. For organizations unable to upgrade immediately, implementing strict input validation on image file headers before passing them to the decoder can help prevent triggering the flawed code path. Additionally, enabling memory sanitizers such as AddressSanitizer during testing phases of custom integrations with OpenImageIO can aid in detecting similar buffer handling errors early in the development lifecycle.

Responsible

GitHub M

Reservation

07/16/2026

Disclosure

09/18/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you need the next level of professionalism?

Upgrade your account now!