CVE-2026-40250

What it actually does

This vulnerability is an integer overflow in OpenEXR's DWA decompression path. In affected 3.2.x, 3.3.x, and 3.4.x releases, the code multiplies a channel width by bytes per element using 32-bit signed arithmetic before widening to a larger allocation or size type. A crafted EXR image with malicious channel metadata can cause the multiplication to wrap, producing an undersized buffer or incorrect length calculation. When the decoder subsequently processes compressed pixel data, this can lead to memory corruption such as out-of-bounds read/write, process crash, or potentially code execution in the context of the application parsing the file. Exploitation requires a victim application or workflow to open or process a malicious EXR file; the CVSS vector indicates local attack with user interaction required and high impact to confidentiality, integrity, and availability of the vulnerable process.

Why it matters to the business

Organizations that ingest, preview, transcode, render, archive, or scan EXR images may be exposed if those workflows use vulnerable OpenEXR versions. A successful attack could crash rendering or media-processing pipelines, corrupt output, or potentially allow attacker-controlled code to run inside desktop creative tools, render workers, asset-management services, or automated file-processing systems. This is especially relevant to film, animation, visual effects, game development, digital asset management, and any product that embeds OpenEXR for image decoding. The issue is not currently listed in CISA KEV, has no known exploit maturity in the supplied data, and has a low, flat EPSS score, so urgency is primarily driven by whether untrusted EXR files are processed automatically or by high-value users.

How an attack unfolds

An attacker creates a malformed EXR file that uses the DWA compression/decompression path and sets channel dimensions and element sizes so that the calculation `chan->width * chan->bytes_per_element` exceeds the range of a 32-bit signed integer. Because the affected code performs the multiplication before casting to a larger type, the result wraps to an incorrect smaller or negative value. The attacker then delivers the file through a route that will cause a vulnerable OpenEXR-linked application to parse it, such as email attachment, shared asset repository, media upload, project file bundle, render queue input, or content pipeline import. When the victim or automated workflow opens or processes the file, OpenEXR miscalculates buffer sizes or offsets during decompression. The immediate observable outcome may be an application crash or abnormal termination; with a reliable exploit, the same memory corruption primitive may be shaped to execute attacker-controlled code with the privileges of the parsing process.

How to fix it

Upgrade OpenEXR to a fixed release line: 3.4.10 or later for 3.4.x deployments, 3.3.10 or later for 3.3.x deployments, or 3.2.8 or later for 3.2.x deployments. Rebuild and redeploy all applications, plugins, containers, render nodes, desktop tools, and services that statically or dynamically link against OpenEXR. If immediate upgrade is not possible, reduce exposure by blocking or quarantining untrusted EXR files, disabling automated EXR processing from untrusted sources, sandboxing image conversion/rendering jobs, running media parsers with least privilege, and isolating render/transcode workers from sensitive systems. Treat embedded copies in third-party creative, rendering, scanning, and asset-management software as in scope even if OpenEXR is not installed as a standalone package.

How to confirm the fix worked

Confirm installed and embedded OpenEXR versions are not in the affected ranges: 3.2.0 through 3.2.7, 3.3.0 through 3.3.9, or 3.4.0 through 3.4.9. Validate that runtime libraries, development packages, container images, and statically linked applications have been rebuilt against 3.2.8, 3.3.10, 3.4.10, or newer. Use package manager inventory, software composition analysis, SBOMs, container scans, and binary dependency inspection to find all OpenEXR copies. Functional validation should include processing known-good EXR files after the upgrade to ensure pipeline compatibility. Where feasible, run malicious-file regression tests or fuzzing harnesses against the DWA decompression path and confirm the vulnerable overflow condition no longer causes crashes or sanitizer findings.

Typical attack path

1. Identify a target workflow or application that accepts EXR images and uses OpenEXR versions 3.2.0-3.2.7, 3.3.0-3.3.9, or 3.4.0-3.4.9.
2. Craft an EXR file using DWA compression and malicious channel metadata that triggers 32-bit integer overflow in the DWA decompressor size calculation.
3. Deliver the file to a user or automated image-processing workflow through an upload, shared media project, email attachment, asset repository, or render/transcode queue.
4. Cause the vulnerable application or service to parse the crafted EXR file.
5. Trigger memory corruption during decompression, resulting in process crash, data exposure/corruption, or potential code execution in the context of the affected process.
6. Use any achieved execution to access files, tamper with media outputs, pivot within the processing environment, or disrupt production workflows.

How to detect it

To determine whether this was already exploited, focus on evidence of crafted EXR files being opened or processed shortly before crashes, abnormal memory faults, or suspicious child processes from media-handling applications. Review application logs, render/transcode job logs, file upload logs, endpoint detection telemetry, crash reporters, operating system event logs, and asset-management audit trails for EXR files processed by vulnerable OpenEXR versions. Look for repeated failures when processing the same EXR asset, segmentation faults, access violations, heap corruption reports, sanitizer findings, or crashes in DWA decompression-related code. Correlate crash timestamps with inbound files from external parties, newly uploaded assets, email attachments, shared project archives, or render queue submissions. For endpoint and server forensics, examine recently processed `.exr` files, quarantine suspicious samples for offline analysis, and check whether image-processing processes spawned unexpected shells, scripting engines, network utilities, credential tools, or persistence mechanisms after parsing EXR content. No public exploit-specific network signature or malware artifact is derivable from the supplied data, so detection should be behavior- and artifact-based rather than IOC-only.

What your security team should do

• Prioritize upgrades first for internet-facing upload services, automated media-processing pipelines, render farms, file preview systems, and endpoints used by staff who receive external media assets.
• Inventory all OpenEXR usage, including transitive dependencies, statically linked binaries, plugins, containers, and vendor-supplied creative or rendering applications.
• Upgrade affected OpenEXR deployments to 3.4.10, 3.3.10, 3.2.8, or later depending on the maintained release branch.
• Temporarily restrict EXR ingestion from untrusted sources until vulnerable components are patched or isolated.
• Run EXR parsing, rendering, thumbnailing, and transcoding jobs in sandboxed, low-privilege environments with filesystem and network restrictions.
• Add monitoring for crashes or abnormal terminations in applications and services that process EXR files, especially following receipt or upload of new EXR assets.
• Ask third-party software vendors whether their products embed vulnerable OpenEXR versions and obtain patched builds where needed.
• Preserve suspicious EXR samples, processing logs, crash dumps, and endpoint telemetry for forensic review if crashes occur during EXR handling.