CVE-2026-34589

What it actually does

OpenEXR versions 3.2.0 through 3.2.6, 3.3.0 through 3.3.8, and 3.4.0 through 3.4.8 contain a memory corruption flaw in the DWA lossy EXR decoder. When decoding a crafted EXR image with sufficiently large dimensions, the decoder performs temporary per-component block pointer calculations using signed 32-bit arithmetic. The calculation can overflow, causing subsequent writes to use a wrapped pointer outside the allocated rowBlock backing buffer. This can lead to process crashes, memory corruption, and potentially code execution in the context of the application or pipeline component parsing the malicious EXR file. The weakness requires a vulnerable application to process a malicious file, so exploitation is typically local or content-ingestion based rather than directly network-facing.

Why it matters to the business

Organizations that ingest, preview, render, convert, scan, or archive EXR image files could experience crashes or compromise of workstations, render nodes, media-processing services, or asset pipelines if a malicious EXR file is opened or automatically processed. This is most relevant to visual effects, animation, post-production, game development, media asset management, and any software supply chain that embeds OpenEXR. Although EPSS is low at 0.00419, has been flat over 30 days, and the issue is not listed in CISA KEV or known ransomware use, the operational impact can be meaningful in environments where untrusted EXR files are routinely handled or processed at scale.

How an attack unfolds

An attacker creates a malformed EXR image using DWA compression and dimensions large enough to trigger signed 32-bit integer overflow during decoder pointer setup. The attacker then delivers the file through a workflow that causes a vulnerable OpenEXR-based application or service to decode it, such as an artist workstation, render farm job, content submission portal, thumbnailer, transcoder, image validation service, or automated asset pipeline. When the file is decoded, the overflowed pointer calculation causes writes outside the intended rowBlock allocation. The immediate observable result may be an application crash or memory safety exception; with additional exploit development, the memory corruption could potentially be shaped into arbitrary code execution under the privileges of the decoding process. No public exploit maturity or active exploitation is currently indicated by the supplied intelligence.

How to fix it

Upgrade OpenEXR to a fixed release: 3.2.7 for the 3.2.x line, 3.3.9 for the 3.3.x line, or 3.4.9 for the 3.4.x line. Because OpenEXR is commonly embedded in graphics, VFX, rendering, asset-management, and image-processing software, remediation should include both system packages and bundled third-party copies. Rebuild statically linked applications, containers, render images, desktop tools, plugins, and CI/CD artifacts that include vulnerable OpenEXR code. Where immediate patching is not possible, reduce exposure by blocking or quarantining untrusted EXR files, disabling automatic EXR thumbnailing or preview generation, restricting DWA-compressed EXR ingestion, sandboxing image-processing workers, and running render or conversion jobs with least privilege and memory-safety crash monitoring.

How to confirm the fix worked

Confirm that all OpenEXR installations and bundled libraries report version 3.2.7, 3.3.9, 3.4.9, or later. Validate operating-system package versions, container images, application bundles, plugin directories, and statically linked binaries rather than relying only on a central package inventory. For source builds, confirm the OpenEXR commit or release tag includes the DWA decoder fix. Exercise representative EXR ingest, preview, render, and conversion workflows after patching to ensure compatibility. If safe test material is available from the vendor or internal security testing, run it only in an isolated environment and verify that the patched decoder rejects or safely handles oversized DWA-compressed images without crashing or producing memory sanitizer findings.

Typical attack path

1. Identify an organization, user, or automated workflow that processes EXR files with an affected OpenEXR version.
2. Craft an EXR file using DWA lossy compression and very large image width or related dimensions to trigger the vulnerable signed 32-bit arithmetic path.
3. Deliver the malicious EXR file through email, file sharing, source asset submission, media upload, project archive, render job, or another content-ingestion channel.
4. Cause a vulnerable application, service, thumbnailer, renderer, or conversion tool to open or decode the file.
5. Trigger out-of-bounds writes outside the allocated rowBlock buffer during DWA decoding.
6. Achieve denial of service through a crash, or potentially gain code execution if the memory corruption is reliably exploited.

How to detect it

To determine whether this was already exploited, review telemetry from systems that ingest or decode EXR files: desktop EDR, application crash logs, render farm job logs, asset pipeline logs, media upload logs, thumbnail generation services, conversion/transcoding services, and core dump repositories. Focus on crashes or memory-corruption alerts in OpenEXR, IlmImf, or DWA decompression code paths shortly after processing newly received EXR files. Look for EXR files using DWAA or DWAB compression with unusually large image dimensions, especially width values that are abnormal for the environment. Correlate suspicious crashes with file provenance, upload source, email attachment source, project archive source, or render job submitter. Preserve suspect EXR files, process memory dumps, sanitizer output, and application logs. Because there are no supplied reports of active exploitation, no actor-specific infrastructure or malware indicators are available; detection should be behavior- and artifact-based.

• .exr
• DWAA_COMPRESSION
• DWAB_COMPRESSION
• compression: dwaa
• compression: dwab
• OpenEXR
• IlmImf
• ImfDwaCompressor
• DwaCompressor::uncompress
• rowBlock
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• integer overflow
• EXR
• DWA

What your security team should do

• Prioritize upgrades on systems that automatically process untrusted or externally supplied EXR files, including render farms, media ingestion services, asset portals, conversion workers, and desktop preview tools.
• Inventory both dynamically installed and bundled or statically linked OpenEXR copies across workstations, containers, render images, build agents, plugins, and third-party creative applications.
• Upgrade to OpenEXR 3.2.7, 3.3.9, 3.4.9, or later, and rebuild dependent applications where OpenEXR is embedded.
• Temporarily restrict untrusted EXR intake, especially DWA-compressed EXR files, until vulnerable processors are patched.
• Run image-processing workloads in sandboxes or low-privilege service accounts to reduce the impact of memory corruption.
• Monitor crash telemetry, EDR alerts, and application logs for OpenEXR DWA decoder crashes or heap corruption associated with recently received EXR files.
• Treat unexpected crashes during EXR preview, render, conversion, or metadata extraction as potentially security-relevant and preserve the triggering file for forensic analysis.