CVE-2026-40244

What it actually does

CVE-2026-40244 is an integer overflow vulnerability in OpenEXR's DWA compression handling. In affected 3.2.x, 3.3.x, and 3.4.x releases, the code calculates an image chunk size using 32-bit signed arithmetic for width multiplied by height. A crafted EXR image with attacker-controlled dimensions can cause that multiplication to wrap, producing an incorrectly small allocation or bounds calculation while later processing assumes the larger logical size. Depending on compiler, platform, allocator behavior, and calling application, this can lead to memory corruption, process crash, or potentially attacker-influenced code execution in software that parses untrusted EXR files.

Why it matters to the business

Organizations that use OpenEXR directly or through image, rendering, media-processing, asset-ingestion, VFX, game, or content pipeline tools may be exposed when users or automated services open untrusted EXR files. The most likely operational impact is application crashes or denial of service in rendering and media workflows, but the CVSS assessment indicates confidentiality, integrity, and availability impact may be high if memory corruption is successfully controlled. The vulnerability is not listed in CISA KEV, has low EPSS, no known exploit maturity, and is not reported as ransomware-used, so urgency is lower than for actively exploited internet-facing flaws; however, file-processing vulnerabilities can become significant where untrusted content is routinely exchanged.

How an attack unfolds

An attacker prepares a malformed EXR image using DWA-compressed data and image dimensions selected to trigger a 32-bit integer overflow during OpenEXR decompression or compression-related processing. The attacker then delivers the file to a target workflow, for example through email, asset upload, shared storage, media exchange, ticket attachment, or a content ingestion pipeline. When a vulnerable application or service using OpenEXR 3.2.0 through 3.2.7, 3.3.0 through 3.3.9, or 3.4.0 through 3.4.9 opens or processes the file, OpenEXR miscalculates the required buffer size. Subsequent reads, writes, or decompression logic can operate outside the intended memory bounds, causing a crash or potentially allowing code execution in the context of the parsing process. Exploitation requires local processing of the malicious file or user/automation interaction; it is not a direct unauthenticated network attack against OpenEXR itself.

How to fix it

Upgrade OpenEXR to a fixed release on every system, application bundle, container image, build environment, and third-party product that embeds or links OpenEXR. Fixed versions are OpenEXR 3.4.10, 3.3.10, and 3.2.8. Prefer upgrading to the latest supported 3.4.x release where compatibility allows. If immediate upgrade is not possible, reduce exposure by blocking or quarantining untrusted EXR files, disabling DWA-compressed EXR ingestion where feasible, processing external media in isolated sandboxed workers, applying strict file size and dimension limits before OpenEXR parsing, and running image-processing services with least privilege and memory-safety mitigations enabled. Rebuild statically linked applications and container images, because upgrading only the system package may not remediate embedded copies.

How to confirm the fix worked

Confirm remediation by inventorying OpenEXR versions from package managers, application manifests, container SBOMs, build artifacts, and statically linked binaries. Verify that no deployed component reports or embeds OpenEXR 3.4.0-3.4.9, 3.3.0-3.3.9, or 3.2.0-3.2.7. Validate that patched builds include OpenEXR 3.4.10, 3.3.10, 3.2.8, or later. For source builds, confirm the fix is present in internal_dwa_compressor.h at the affected calculation and that width and height multiplication is promoted to size_t or otherwise checked for overflow. Where test harnesses are available, run regression tests or fuzz cases covering large DWA-compressed EXR dimensions and confirm they fail safely without crash, sanitizer findings, or out-of-bounds memory access.

Typical attack path

1. Identify software, render nodes, media services, or asset-ingestion pipelines that use a vulnerable OpenEXR release.
2. Create a malicious EXR file with DWA compression and crafted dimensions that cause width multiplied by height to overflow 32-bit arithmetic.
3. Deliver the file to a user or automated processing workflow through upload, shared asset repository, email, collaboration platform, or media exchange.
4. Trigger parsing of the file by a vulnerable OpenEXR-linked application or service.
5. Cause memory corruption during DWA compressor/decompressor handling, resulting in a crash or possible execution of attacker-controlled behavior depending on exploit reliability and runtime protections.
6. Use the compromised process context, if code execution is achieved, to access files, credentials, project data, or connected pipeline resources.

How to detect it

Look for evidence that vulnerable applications processed suspicious EXR files shortly before crashes, abnormal exits, sanitizer findings, or EDR memory-corruption alerts. Useful sources include application logs from render/media tools, asset-ingestion service logs, upload gateways, file transfer logs, EDR process telemetry, crash dumps, core dumps, Windows Error Reporting, macOS crash reports, Linux syslog/journald, container logs, and CI job logs. Focus on crashes involving OpenEXR DWA compressor/decompressor code, EXR files with unusually large width or height values, external uploads followed by process termination, and repeated attempts to process the same EXR file. If core dumps or crash reports are available, inspect stack traces for OpenEXR DWA paths and memory errors around integer overflow, allocation size mismatch, heap corruption, or out-of-bounds access. There are no public threat actors or known exploitation campaigns associated with this CVE in the provided data, so detection should emphasize behavioral evidence of malicious file processing rather than actor-specific indicators.

• internal_dwa_compressor.h:1722
• internal_dwa_compressor.h
• DwaCompressor
• DWA compressor
• OpenEXR
• ImfDwaCompressor
• Imf_3_2
• Imf_3_3
• Imf_3_4
• integer overflow
• signed integer overflow
• heap-buffer-overflow
• heap buffer overflow
• out-of-bounds
• malloc(): corrupted top size
• double free or corruption
• corrupted size vs. prev_size
• EXR
• \.exr

What your security team should do

• Inventory all OpenEXR usage, including media tools, render farms, CI/CD image-processing jobs, container images, plugins, and third-party desktop applications that may bundle the library.
• Prioritize patching systems that automatically process untrusted EXR files or accept external media uploads, even though current EPSS is low and there is no KEV listing.
• Upgrade to OpenEXR 3.4.10, 3.3.10, 3.2.8, or later, and rebuild any statically linked software.
• Temporarily route untrusted EXR processing through sandboxed, non-privileged workers with network egress restrictions and resource limits.
• Add pre-ingestion controls for EXR files, including file type validation, maximum dimension checks, maximum file size limits, and quarantine of unexpected DWA-compressed content.
• Review crash telemetry, EDR alerts, and application logs for recent OpenEXR-related crashes after processing external EXR files, especially since publication on 2026-04-21.
• Ensure media-processing services run with least privilege and cannot directly access sensitive credentials or broad shared storage if parser compromise occurs.