CVE-2026-34379: OpenEXR has a misaligned write in LossyDctDecoder_execute leading to undefined behavior (DWA/DWAB decompression)
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.
Security readout for executives and security teams
Plain-English summary
CVE-2026-34379 is a high-severity OpenEXR flaw where certain compressed EXR images can trigger unsafe memory writes during decoding. A crafted DWA or DWAB file with FLOAT channels may crash image-processing systems, especially on ARM or RISC-V. Fixed OpenEXR releases are available.
Executive priority
Treat as a high-priority patch for organizations processing external image assets. The business risk is service disruption in media or rendering workflows, with higher urgency where EXR files cross trust boundaries or run in automated pipelines.
Technical view
Affected OpenEXR 3.2.0-3.2.6, 3.3.0-3.3.8, and 3.4.0-3.4.8 perform an in-place HALF-to-FLOAT conversion in LossyDctDecoder_execute by casting a potentially unaligned uint8_t row pointer to float*. This is undefined behavior, causing alignment faults on strict architectures and optimizer-dependent risk elsewhere.
Likely exposure
Exposure is most likely in render farms, VFX tools, media ingestion services, thumbnailers, converters, or applications that decode user-supplied EXR files through affected OpenEXR versions. ARM and RISC-V systems have higher immediate crash risk, but x86 builds still carry undefined-behavior risk.
Exploitation context
The provided sources do not show CISA KEV listing, active exploitation, or public weaponization. Exploitation requires an affected decoder to process a crafted DWA or DWAB-compressed EXR containing a FLOAT-type channel. The documented impact is availability loss and possible integrity impact, not confirmed remote code execution.
Researcher notes
Evidence is strongest for an alignment-based undefined behavior bug in OpenEXR’s DWA decoder. The source bundle names exact vulnerable ranges and fixed versions. It does not prove active exploitation or provide enough evidence to claim code execution beyond crash and integrity risk.
Mitigation direction
Upgrade OpenEXR to 3.2.7, 3.3.9, 3.4.9, or later applicable fixed releases.
Check operating-system vendor advisories for backported OpenEXR security fixes.
Prioritize automated media-processing pipelines that accept external EXR files.
Restrict or quarantine untrusted EXR uploads until patched.
Rebuild statically linked applications that bundle affected OpenEXR code.
Validation and detection
Inventory OpenEXR versions in packages, containers, build artifacts, and bundled dependencies.
Confirm whether applications accept or generate DWA or DWAB-compressed EXR files.
Verify production runtimes use fixed OpenEXR versions or vendor-patched packages.
Review SBOMs for statically linked or vendored OpenEXR copies.
Track crash reports from EXR decoding on ARM, RISC-V, and optimized x86 builds.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-475: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.