CVE-2026-34379

What it actually does

CVE-2026-34379 is a memory-corruption flaw in OpenEXR's DWA/DWAB decompression path. When an affected OpenEXR version decodes a crafted EXR image containing a FLOAT-type channel, LossyDctDecoder_execute() may cast an unaligned byte buffer pointer to a float pointer and write through it during an in-place HALF-to-FLOAT conversion. On alignment-enforcing architectures such as ARM and RISC-V, this can immediately terminate the process with an alignment fault. On x86, the write is often tolerated by hardware, but the undefined behavior can still produce incorrect writes or optimizer-dependent behavior. The most reliable technical impact is application crash and denial of service; limited data integrity impact is possible where malformed image decoding corrupts output or adjacent processing state.

Why it matters to the business

Organizations using affected OpenEXR releases in image-processing pipelines, render farms, media ingestion services, asset management platforms, content validation tools, or applications that preview EXR files could experience crashes when a malicious or malformed EXR file is processed. The operational impact is highest where EXR files are accepted from external users, vendors, creative partners, or automated workflows, because a single crafted file may interrupt batch jobs, rendering, transcoding, thumbnailing, or review systems. The current EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, but exposure can be broad because OpenEXR is commonly embedded as a library inside many graphics, VFX, animation, and image-processing products.

How an attack unfolds

An attacker creates a specially malformed EXR file using DWA or DWAB compression and at least one FLOAT-type channel arranged so that the decoder's row buffer is not 4-byte aligned during conversion. The attacker then causes a vulnerable application or service to parse the file, typically by uploading it, sending it as an asset, placing it in a watched processing directory, attaching it to a workflow, or convincing a user to open it. When the affected OpenEXR decoder reaches LossyDctDecoder_execute(), it performs an in-place HALF-to-FLOAT conversion through an improperly aligned float pointer. On architectures that enforce aligned memory access, the application is likely to crash immediately. On other platforms, the behavior may be less obvious but remains unsafe because compiler optimizations can assume proper alignment. No active exploitation, ransomware use, or named threat actor activity is currently indicated by the supplied intelligence.

How to fix it

Upgrade OpenEXR to a fixed release: 3.2.7, 3.3.9, 3.4.9, or later, depending on the branch in use. Because OpenEXR is often bundled into downstream applications, also update statically linked binaries, containers, desktop tools, render nodes, plugins, and image-processing packages that embed vulnerable OpenEXR code. Where immediate upgrade is not possible, reduce exposure by blocking or quarantining untrusted EXR uploads, disabling DWA/DWAB-compressed EXR processing where feasible, converting EXR files through a patched isolation service, and sandboxing image decoders with resource limits and crash containment. Prioritize systems that automatically process externally supplied EXR files or run on ARM/RISC-V platforms where the crash behavior is most reliable.

How to confirm the fix worked

Confirm the deployed OpenEXR library version is 3.2.7, 3.3.9, 3.4.9, or later. Validate both package-manager installations and embedded copies inside applications, containers, plugins, and statically linked tools. Use software composition analysis, package inventory, container image scanning, and binary inspection to identify libOpenEXR or OpenEXRCore versions. Where safe and authorized, test representative applications with a known malformed DWA/DWAB EXR regression sample in a non-production environment and confirm the application no longer crashes. Review build manifests and dependency lockfiles to ensure all OpenEXR branches have been updated, then restart or redeploy services so patched libraries are actually loaded.

Typical attack path

1. Identify an application, service, or workflow that uses OpenEXR versions 3.2.0 through before 3.2.7, 3.3.9, or 3.4.9 to decode EXR images.
2. Craft an EXR file using DWA or DWAB compression with a FLOAT-type channel that triggers the misaligned in-place conversion path.
3. Deliver the file through an accepted image-ingestion route such as upload, email attachment, shared asset repository, automated render pipeline, or user-assisted file opening.
4. Wait for the vulnerable application or background processor to decode the EXR file.
5. Trigger a crash, job failure, service restart, or corrupted processing output when LossyDctDecoder_execute() writes through the misaligned pointer.

How to detect it

Look for evidence that EXR parsing applications crashed or faulted while processing DWA or DWAB-compressed EXR files. Relevant log sources include application logs for media ingestion and rendering services, crash reporters, core dump managers, systemd journals, container runtime logs, EDR process telemetry, file upload/audit logs, and batch job scheduler logs. On ARM and RISC-V systems, prioritize SIGBUS, alignment fault, bus error, or unaligned access messages associated with tools or services that load OpenEXR. Correlate crashes with recently received or processed .exr files, especially files from external users or partners. For forensic review, preserve the triggering EXR file, application stderr/stdout, core dumps, stack traces, and hashes of suspect input files. A stack trace referencing LossyDctDecoder_execute() or OpenEXRCore DWA decode paths is a strong indicator of attempted or accidental triggering. There are no known public exploit campaigns or threat actor indicators provided, so detection should focus on malformed-file processing artifacts rather than network-based signatures.

• LossyDctDecoder_execute
• internal_dwa_decoder.h:749
• OpenEXRCore
• DWA_COMPRESSION
• DWAB_COMPRESSION
• SIGBUS
• Bus error
• alignment fault
• unaligned access
• .exr

What your security team should do

• Inventory applications, containers, render nodes, media-processing services, and desktop tools that parse EXR files or include OpenEXR.
• Upgrade OpenEXR to 3.2.7, 3.3.9, 3.4.9, or later, including embedded or statically linked copies.
• Prioritize internet-facing, partner-facing, or automated file-ingestion workflows that accept EXR assets from untrusted sources.
• Temporarily restrict untrusted EXR uploads or disable DWA/DWAB-compressed EXR processing until patching is complete.
• Run image decoders in sandboxed, least-privilege environments with crash isolation, memory limits, and automated job quarantine.
• Search historical crash logs and processing failures for OpenEXR DWA/DWAB decode crashes, especially SIGBUS or alignment-related faults on ARM and RISC-V systems.
• Coordinate with vendors of graphics, VFX, rendering, animation, and asset-management products to confirm whether their builds include a fixed OpenEXR version.