CVE-2026-63419 Overview
CVE-2026-63419 is a heap out-of-bounds write vulnerability in OpenImageIO, an open-source toolset for reading, writing, and manipulating image files used throughout VFX and animation pipelines. The flaw affects the IFF input plugin when handling zbuffer-only tiled IFF images. The public ImageSpec reports a 16-bit pixel size, while the internal decoder retains a 32-bit pixel size. A crafted IFF file triggers a mismatched copy into an undersized caller buffer, corrupting heap memory. The issue is fixed in versions 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1. It is classified under [CWE-787] (Out-of-Bounds Write).
Critical Impact
An attacker who convinces a user to open a malicious IFF file can trigger heap memory corruption, enabling arbitrary code execution in the context of the process consuming OpenImageIO.
Affected Products
- OpenImageIO versions prior to 3.0.21.0
- OpenImageIO 3.1.x versions prior to 3.1.16.0
- OpenImageIO 3.2.x versions prior to 3.2.0.3-beta1
Discovery Timeline
- 2026-09-18 - CVE-2026-63419 published to the National Vulnerability Database (NVD)
- 2026-09-24 - Last updated in NVD database
Technical Details for CVE-2026-63419
Vulnerability Analysis
The vulnerability resides in src/iff.imageio/iffinput.cpp, specifically inside IffInput::read_native_tile(). OpenImageIO exposes a public ImageSpec describing a zbuffer-only tiled IFF image as having 16-bit pixels. Internally, however, the decoder tracks the IFF pixel layout using m_header.pixel_bytes(), which reflects the true 32-bit width for ZBUFFER data.
When read_native_tile() copies decoded pixels into the caller-provided tile buffer, it uses m_header.pixel_bytes() for the copy length instead of ImageSpec::tile_bytes(true). The caller sizes its buffer based on the advertised 16-bit spec, so the copy overruns that buffer. The result is a heap out-of-bounds write and memory corruption.
A secondary condition compounds the flaw. A failed read leaves the internal buffer m_buf in a non-empty state. A subsequent call then copies partially initialized data into the undersized buffer, providing attacker influence over the corrupt contents.
Root Cause
The root cause is inconsistent state between the public ImageSpec (16-bit pixel bytes) and the internal m_header (32-bit pixel bytes) for the ZBUFFER code path. The copy length in read_native_tile() is derived from the internal header rather than the spec used to size the destination buffer, producing a boundary mismatch.
Attack Vector
Exploitation is local and requires user interaction. A victim must open, preview, or process a malicious IFF file through an application that links against a vulnerable OpenImageIO build. This includes VFX and animation tooling, asset ingestion pipelines, thumbnailers, and rendering services that accept untrusted IFF inputs. Successful exploitation produces heap corruption that can be shaped toward arbitrary code execution in the host process.
No verified public exploit code is available. See the GitHub Security Advisory GHSA-w6wc-gcf4-5pj2 and the fix commit for full technical detail.
Detection Methods for CVE-2026-63419
Indicators of Compromise
- Unexpected crashes, aborts, or heap corruption reports in processes that load IFF files through OpenImageIO (oiiotool, iinfo, DCC applications, render nodes).
- IFF files whose declared zbuffer channel layout is inconsistent with published spec fields (16-bit exposed vs. 32-bit internal pixel size).
- Address Sanitizer (ASan) heap-buffer-overflow reports originating in IffInput::read_native_tile().
Detection Strategies
- Inventory hosts and container images containing OpenImageIO shared libraries and match versions against the fixed releases 3.0.21.0, 3.1.16.0, and 3.2.0.3-beta1.
- Run fuzzing or ASan-instrumented decode against untrusted IFF samples to surface heap out-of-bounds writes in the IFF plugin.
- Monitor endpoint telemetry for abnormal child processes, memory faults, or code execution originating from image ingestion workflows.
Monitoring Recommendations
- Alert on crash events in build farms, render nodes, and asset pipelines that process IFF assets from external contributors or vendors.
- Track file-open events for .iff and .z files handled by applications linked to vulnerable OpenImageIO versions.
- Correlate crash telemetry with subsequent process spawns or unexpected outbound network activity to identify post-exploitation behavior.
How to Mitigate CVE-2026-63419
Immediate Actions Required
- Upgrade OpenImageIO to 3.0.21.0, 3.1.16.0, or 3.2.0.3-beta1 or later across all workstations, render nodes, and container images.
- Rebuild and redistribute any downstream applications, plugins, or Docker images that statically link or vendor OpenImageIO.
- Restrict ingestion of IFF files to trusted sources until patched builds are deployed across the pipeline.
Patch Information
The fix is available in OpenImageIO releases v3.0.21.0 and v3.1.16.0, and in the 3.2.0.3-beta1 prerelease. The change is tracked in Pull Request #5268 and lands in the upstream fix commit, aligning the copy length in IffInput::read_native_tile() with ImageSpec::tile_bytes(true) and clearing m_buf on read failure.
Workarounds
- Disable or unregister the IFF input plugin in OpenImageIO deployments where IFF support is not required.
- Sandbox image decoding processes with seccomp, AppArmor, or container isolation to limit blast radius of memory corruption.
- Pre-validate incoming IFF files with a hardened parser or reject files that declare zbuffer-only tiled layouts until patching completes.
# Configuration example: verify installed OpenImageIO version and remove vulnerable builds
oiiotool --version
pip show OpenImageIO | grep -i version
ldconfig -p | grep -i OpenImageIO
# Rebuild from a fixed release tag
git clone https://github.com/AcademySoftwareFoundation/OpenImageIO.git
cd OpenImageIO
git checkout v3.1.16.0
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel
cmake --install build
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

