Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:HSummary
CVE-2026-34379 is a high-severity Incorrect Type Conversion or Cast (CWE-704) vulnerability in Openexr Openexr. Its CVSS base score is 7.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 21th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-34379 is a misaligned memory write vulnerability in the OpenEXR library, which provides the specification and reference implementation for the EXR file format used in the motion picture industry for image storage. The issue resides in the LossyDctDecoder_execute() function at src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file with a FLOAT-type channel, the decoder performs an in-place HALF-to-FLOAT conversion by casting an unaligned uint8_t* row pointer to float* and writing through it. This results in undefined behavior under the C standard because the row buffer may not be 4-byte aligned, leading to immediate crashes on architectures enforcing alignment such as ARM and RISC-V. On x86, it is tolerated at runtime but remains exploitable due to compiler optimizations assuming aligned access. Affected versions range from 3.2.0 up to but not including 3.2.7, 3.3.9, and 3.4.9. The vulnerability carries a CVSS v3.1 base score of 7.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H) and is associated with CWEs 704 (Incorrect Type Conversion or Cast), 787 (Out-of-bounds Write), and 843 (Access of Resource Using Incompatible Type).
An attacker can exploit this vulnerability remotely with low complexity and no privileges by tricking a user into opening a specially crafted DWA or DWAB-compressed EXR file containing a FLOAT-type channel. User interaction is required, such as processing the file in an application that uses vulnerable OpenEXR versions for decoding. Successful exploitation triggers undefined behavior, typically causing application crashes due to the misaligned write, which disrupts availability with high impact. On x86 systems, it may enable further code execution or memory corruption via compiler optimizations, with low integrity impact but no confidentiality loss.
Mitigation is available through patches released by the Academy Software Foundation. Vulnerable versions should be upgraded to OpenEXR 3.2.7, 3.3.9, or 3.4.9, with corresponding release notes and binaries provided on GitHub. Additional details are documented in the project's security advisory at GHSA-w88v-vqhq-5p24.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-19305
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.5.2V3.2.3V15.3.5
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (static analysis, fuzzing, unit tests) directly finds incorrect type conversions or casts.
Validating inputs to API control parameters ensures only permitted values are supplied, structurally eliminating the source of undefined behavior.
Requiring documented development standards and tools can mandate safe typing, casting rules, and compiler checks that stop the weakness from being introduced.
Security engineering principles can require type-safe design and casting practices that structurally avoid incorrect conversions.
Memory-protection mechanisms limit the exploitability and blast radius of a successful out-of-bounds write.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent type-conversion flaws via coding standards, reviews, and testing.
Vulnerability scanning and recording can discover out-of-bounds write flaws so they can be remediated.
Patching or replacing vulnerable software directly eliminates known instances of this coding weakness.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can uncover type-conversion defects before release.
Secure development lifecycle includes type-safety reviews that reduce incorrect casts.
Application security requirements can mandate strong typing and safe casting rules.
Secure architecture principles discourage unsafe type conversions in design.
Secure coding standards directly forbid or detect incorrect type casts.
Change management can enforce review gates that catch unsafe memory operations before deployment.