Raw vector
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-40250 is a high-severity Integer Overflow or Wraparound (CWE-190) vulnerability in Openexr Openexr. Its CVSS base score is 8.4 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 37th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — 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-40250 is an integer overflow vulnerability (CWE-190) in the OpenEXR library, the reference implementation and specification for the EXR image file format widely used in the motion picture industry. The flaw affects versions 3.4.0 through 3.4.9, 3.3.0 through 3.3.9, and 3.2.0 through 3.2.7, specifically in the file internal_dwa_compressor.h at line 1040. There, the computation chan->width * chan->bytes_per_element uses int32 arithmetic without a cast to size_t, enabling an overflow. This follows the same pattern previously fixed in other decoders by CVE-2026-34589, CVE-2026-34588, and CVE-2026-34544, but was missed in this instance.
The vulnerability carries a CVSS v3.1 base score of 7.1 (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H). Local attackers with no privileges required can exploit it with low complexity by tricking users into processing a crafted malicious EXR file via an application linked to the vulnerable OpenEXR library. Successful exploitation enables high-impact integrity and availability effects, such as memory corruption, arbitrary code execution, or denial of service, while confidentiality remains unaffected.
Mitigation is provided in OpenEXR releases 3.4.10, 3.3.10, and 3.2.8, which address the overflow at internal_dwa_compressor.h:1040. Security advisories and release notes, including GitHub security advisory GHSA-m5qw-23x2-6phj, recommend updating to these fixed versions in all dependent software to prevent exploitation.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-24047
Vulnerability Data
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.4.0 through 3.4.9, 3.3.0 through 3.3.9, and 3.2.0 through 3.2.7, `internal_dwa_compressor.h:1040` performs `chan->width * chan->bytes_per_element` in `int32`…
more
arithmetic without a `(size_t)` cast. This is the same overflow pattern fixed in other decoders by CVE-2026-34589/34588/34544, but this line was missed. Versions 3.4.10, 3.3.10, and 3.2.8 contain a fix that addresses `internal_dwa_compressor.h:1040`.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V5.2.6
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (static analysis, fuzzing, unit tests) directly finds integer overflow defects before deployment.
Secure engineering principles require use of safe arithmetic constructs or language features that structurally eliminate integer overflow during calculation.
Input validation enforces bounds on values before arithmetic, stopping the conditions that trigger overflow or wraparound.
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 require use of safe arithmetic, bounds checks, and testing that prevent integer overflows.
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 in development can detect integer overflows before release.
Secure SDLC mandates input validation and arithmetic checks that prevent integer overflows.
Application security requirements include bounds checking and safe arithmetic to avoid overflow conditions.
Secure architecture principles require defensive coding patterns that mitigate integer wraparound risks.
Secure coding standards explicitly forbid unsafe integer operations and mandate overflow-safe constructs.