CVE-2026-59984

What it actually does

Out-of-bounds write in uncompress_b44_impl() on ILP32 builds when a crafted B44-compressed scanline EXR causes scratch buffer size truncation before allocation, resulting in attacker-controlled channel width writes that produce memory corruption and denial of service.

Why it matters to the business

Applications and pipelines that process OpenEXR images may crash or become unstable when handling malicious files, disrupting rendering, compositing, and post-production workflows in media environments that depend on the library.

How an attack unfolds

An attacker creates a specially crafted B44-compressed EXR file that triggers truncation of the logical scratch buffer size; when a vulnerable application opens the file, uncompress_b44_impl() performs writes using the attacker-supplied channel width, corrupting memory and potentially crashing the process.

How to fix it

Upgrade OpenEXR to version 3.2.11 or later, 3.3.13 or later, or 3.4.14 or later on all ILP32 builds; rebuild and redeploy any dependent applications or containers; verify that image-processing pipelines use the patched library versions.

How to confirm the fix worked

Confirm installed OpenEXR version meets or exceeds 3.2.11, 3.3.13, or 3.4.14; test processing of known-good and boundary EXR files to ensure no crashes; review build configurations to confirm ILP32 targets are updated.

Typical attack path

1. Attacker generates malicious B44-compressed scanline EXR with manipulated channel width
2. Victim opens the file using an application linked against a vulnerable OpenEXR build on an ILP32 platform
3. Library allocates truncated scratch buffer and uncompress_b44_impl() writes beyond bounds
4. Memory corruption occurs, leading to denial of service or potential further exploitation

How to detect it

Review application logs and crash reports for segmentation faults or memory errors during EXR file processing; examine file-handling code paths for recent B44-compressed scanline EXR inputs; no public exploitation indicators are known at this time.

What your security team should do

• Prioritize patching OpenEXR in all media, VFX, and rendering environments within the next sprint
• Inventory applications and containers that statically or dynamically link OpenEXR and schedule upgrades
• Add OpenEXR version checks to continuous integration and deployment pipelines
• Monitor upstream releases for any follow-on fixes or additional affected branches