CVE-2026-41142

What it actually does

This is an integer overflow in OpenEXR's ImageChannel::resize functionality reachable through the OpenEXRUtil public API. A crafted EXR image can cause size calculations to wrap, leading to an undersized heap allocation followed by an out-of-bounds heap write. In software that parses untrusted EXR files, this can result in process crashes, memory corruption, and potentially arbitrary code execution in the context of the vulnerable application. The CVSS vector indicates network-adjacent delivery is plausible through services or applications that accept uploaded or remotely supplied image files, but exploitation requires user or application interaction with a malicious EXR file.

Why it matters to the business

Organizations using vulnerable OpenEXR versions in image-processing, rendering, media pipeline, asset ingestion, thumbnailing, transcoding, or content validation workflows could experience application crashes, corrupted processing jobs, service disruption, or compromise of systems that process untrusted image content. The risk is most important for internet-facing upload pipelines and automated media-processing services because a malicious file could trigger the flaw without requiring direct attacker access to the host. The issue is not currently listed in CISA KEV, has no known ransomware association, and has a low, flat EPSS score, which lowers evidence of active exploitation, but the high CVSS impact and memory-corruption nature still warrant timely remediation.

How an attack unfolds

An attacker creates a malformed EXR file with image channel metadata or dimensions designed to trigger an integer overflow inside ImageChannel::resize. The attacker then delivers the file to software that uses affected OpenEXR versions, such as through a file upload feature, media ingestion workflow, rendering pipeline, email attachment, shared asset repository, or any service that automatically parses EXR images. When the vulnerable application calls the OpenEXRUtil API and resizes the affected image channel, the overflow causes an incorrect heap allocation size. Subsequent writes exceed the allocated buffer, corrupting heap memory. In the simplest case, the application crashes and causes denial of service. With exploit development, heap corruption may be shaped to overwrite control data and potentially execute attacker-controlled code under the privileges of the parsing process. No public exploit maturity or named threat-actor exploitation is currently indicated by the supplied intelligence.

How to fix it

Upgrade OpenEXR to a patched release. Affected version ranges are 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11. Fixed versions are 3.2.9, 3.3.11, and 3.4.11. Where possible, upgrade to the latest stable OpenEXR release available from the trusted package source for the operating system, language ecosystem, or vendor distribution. Rebuild and redeploy all statically linked applications, containers, media-processing services, plugins, and desktop tools that bundle OpenEXR, because updating the system library alone may not remediate embedded copies. If immediate upgrade is not possible, reduce exposure by rejecting or quarantining untrusted EXR files, disabling EXR processing where not required, running image parsing in a sandboxed low-privilege process, enforcing file size and dimension limits, and isolating render or media ingestion workers from sensitive systems.

How to confirm the fix worked

Confirm the effective OpenEXR version used at runtime, not only the package version installed on the host. Check package managers, container images, build manifests, software bills of materials, and application dependency locks for OpenEXR versions in the affected ranges. For dynamically linked software, verify linked library versions with platform-appropriate tooling such as package manager queries and shared-library inspection. For statically linked or vendor-bundled tools, confirm the vendor has rebuilt against OpenEXR 3.2.9, 3.3.11, 3.4.11, or later. Validate that upload and ingestion controls reject unexpected EXR content if mitigation is being used. In test environments, use fuzzing or vendor-provided regression tests to confirm malformed EXR inputs no longer crash the application; do not test production systems with untrusted proof-of-concept files.

Typical attack path

1. Identify an application, service, plugin, or workflow that processes EXR images using OpenEXR versions 3.0.0 through before 3.2.9, 3.3.0 through before 3.3.11, or 3.4.0 through before 3.4.11.
2. Craft a malicious EXR file whose channel sizing data triggers integer overflow in ImageChannel::resize.
3. Deliver the malicious EXR file through an upload form, automated asset ingestion process, rendering queue, email attachment, shared storage location, or other content-processing path.
4. Wait for the target application to parse the EXR file using the vulnerable OpenEXRUtil API.
5. Trigger heap out-of-bounds write during channel resize, causing memory corruption.
6. Use the resulting condition to crash the service, corrupt processing output, or attempt code execution in the context of the vulnerable process.

How to detect it

Look for evidence that malformed EXR files were processed before patching. Relevant log sources include application upload logs, media ingestion logs, render farm job logs, thumbnailing or transcoding service logs, web server access logs for EXR uploads, endpoint crash reports, EDR process telemetry, core dump records, container restart events, and operating system logs. Investigate crashes or abnormal exits in applications that parse EXR files, especially shortly after receiving files with .exr extensions or EXR content types. Search crash stacks and sanitizer output for ImageChannel::resize, OpenEXRUtil, heap-buffer-overflow, out-of-bounds write, segmentation faults, aborts, or allocator corruption messages. Review recent EXR files from untrusted sources, unusually large or malformed image dimensions, repeated upload attempts followed by service crashes, and any unexpected child processes or network connections spawned by image-processing services after EXR parsing. There are no known threat actors or public exploitation campaigns in the supplied intelligence, so detection should focus on behavioral artifacts, crash correlation, suspicious file submissions, and post-crash process activity rather than campaign-specific indicators.

• ImageChannel::resize
• OpenEXRUtil
• heap-buffer-overflow
• out-of-bounds write
• integer overflow
• OpenEXR
• IlmImf
• EXR
• \.exr
• image/exr
• image/x-exr
• Segmentation fault
• SIGSEGV
• malloc(): corrupted top size
• malloc(): invalid size
• corrupted double-linked list
• double free or corruption
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: SEGV
• core dumped

What your security team should do

• Inventory applications, containers, render nodes, media pipelines, desktop tools, and third-party products that parse EXR files or include OpenEXR.
• Prioritize remediation for internet-facing upload services, automated image-processing workers, shared asset ingestion systems, and any workflow that processes files from untrusted users.
• Upgrade OpenEXR to 3.2.9, 3.3.11, 3.4.11, or a later fixed release, and rebuild statically linked software or container images.
• Temporarily block, quarantine, or require additional validation for EXR files from untrusted sources until patching is complete.
• Run EXR processing with least privilege, sandboxing, resource limits, and network isolation to reduce the impact of memory corruption.
• Search crash telemetry and application logs for signs of parsing failures involving OpenEXR, EXR files, ImageChannel::resize, or heap-buffer-overflow conditions.
• Add dependency and SBOM checks to detect vulnerable OpenEXR versions in future builds and vendor-supplied packages.
• Because EPSS is currently low and there is no KEV listing, schedule remediation based on exposure: urgent for untrusted file-processing paths, standard patch cycle for isolated trusted-only workflows.