CVE-2026-34545

What it actually does

CVE-2026-34545 is a heap-based buffer overflow in OpenEXR versions 3.4.0 through 3.4.6 when decoding crafted EXR images that use HTJ2K compression with a channel width of 32768. During image decode, the library can write attacker-controlled data past the end of an output heap buffer in repeated 2-byte or 4-byte increments for each pixel beyond the overflow boundary. In applications that parse untrusted EXR files, this memory corruption can cause crashes, denial of service, or potentially remote code execution in the context of the process performing the image decode.

Why it matters to the business

Organizations using vulnerable OpenEXR versions in image processing pipelines, digital content tools, render farms, asset ingestion systems, media review platforms, or any application that automatically opens EXR files may be exposed to compromise through a malicious image file. Successful exploitation could disrupt production workflows, crash processing services, or allow an attacker to execute code on systems that process the file. Although EPSS is currently low at 0.00611, unchanged over 30 days, and the issue is not listed in CISA KEV, the impact is high where EXR files are accepted from external or semi-trusted sources because exploitation requires only user or workflow interaction with a crafted file.

How an attack unfolds

An attacker creates a malicious .exr image that uses HTJ2K compression and a channel layout designed to trigger the vulnerable channel width handling, specifically a width of 32768. The attacker then delivers the file to a target workflow, such as through email, file sharing, asset upload, vendor content exchange, media ingestion, or a repository containing image assets. When a vulnerable application linked against OpenEXR 3.4.0 through 3.4.6 opens, previews, validates, converts, renders, or otherwise decodes the EXR file, the library writes beyond the allocated heap buffer. Depending on heap layout, platform protections, and application behavior, this may result in a crash or may be shaped into controlled memory corruption that enables code execution under the privileges of the decoding application or service.

How to fix it

Upgrade OpenEXR to version 3.4.7 or later wherever the library is used directly or bundled into applications. Because OpenEXR is commonly embedded in media, graphics, rendering, and content-processing software, inventory both system packages and vendor-supplied application copies. Rebuild statically linked applications against the patched library. Where immediate patching is not possible, reduce exposure by blocking or quarantining untrusted EXR files, disabling HTJ2K-compressed EXR decoding if supported, processing untrusted media in sandboxed or isolated environments, running image processing services with least privilege, and disabling automatic preview or conversion of externally supplied EXR files.

How to confirm the fix worked

Confirm installed or bundled OpenEXR versions are not in the vulnerable range 3.4.0 through 3.4.6 and that they have been upgraded to 3.4.7 or later. Validate package versions using the operating system package manager, application dependency manifests, container image scans, software composition analysis, and binary inspection for statically bundled copies. For applications that process EXR files, perform a controlled regression test with representative EXR content and confirm decoding remains functional after upgrade. For exposure validation, identify services, scripts, render workers, web applications, and desktop tools that accept .exr files or invoke OpenEXR utilities, then confirm they no longer use a vulnerable library path.

Typical attack path

1. Identify an organization, tool, pipeline, or service that accepts or processes EXR image files.
2. Craft an EXR file using HTJ2K compression with channel dimensions that trigger the vulnerable buffer handling path, including a channel width of 32768.
3. Deliver the crafted .exr file through an ingestion portal, shared asset package, email attachment, source repository, content vendor exchange, or other file-transfer workflow.
4. Wait for a vulnerable application or automated process using OpenEXR 3.4.0 through 3.4.6 to decode the image.
5. Trigger heap memory corruption during decode, resulting in application crash or potentially attacker-controlled code execution.
6. Use any achieved code execution to access files, credentials, production assets, render infrastructure, or adjacent systems available to the compromised process.

How to detect it

Review logs and forensic artifacts from systems that process EXR files for evidence of crashes, abnormal exits, or memory corruption shortly after opening .exr files. Useful sources include application logs from image conversion, rendering, preview, asset ingestion, and media processing tools; operating system crash logs; core dumps; endpoint detection telemetry; file upload records; email and collaboration platform attachment logs; web access logs for .exr uploads; and job scheduler or render farm worker logs. Look for suspicious or newly introduced EXR files that use HTJ2K compression, have unusual dimensions or channel metadata, or repeatedly cause deterministic crashes. Investigate segmentation faults, heap corruption messages, access violations, or sanitizer findings in processes linked to OpenEXR. If endpoint telemetry is available, look for child processes, network connections, or file writes spawned unexpectedly by image-processing applications after EXR decode. No public threat actors or active exploitation campaigns are currently identified from the provided data, and the CVE is not listed in KEV, but crash-driven detection is still important because exploitation may appear first as instability in automated media workflows.

• OpenEXR 3.4.0
• OpenEXR 3.4.1
• OpenEXR 3.4.2
• OpenEXR 3.4.3
• OpenEXR 3.4.4
• OpenEXR 3.4.5
• OpenEXR 3.4.6
• .exr
• HTJ2K
• channel width 32768
• width=32768
• Segmentation fault
• heap-buffer-overflow
• heap buffer overflow
• heap corruption
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid pointer
• double free or corruption
• AddressSanitizer: heap-buffer-overflow
• EXCEPTION_ACCESS_VIOLATION
• SIGSEGV
• core dumped

What your security team should do

• Prioritize patching systems and applications that automatically process EXR files from external parties, vendors, users, customers, shared repositories, or production asset exchanges.
• Upgrade OpenEXR to 3.4.7 or later and rebuild any internally maintained software that statically links OpenEXR.
• Ask vendors of image, VFX, rendering, media management, and asset pipeline products whether their products bundle OpenEXR 3.4.0 through 3.4.6 and obtain patched releases.
• Temporarily restrict or sandbox processing of untrusted .exr files, especially HTJ2K-compressed files, until all affected components are upgraded.
• Add monitoring for crashes in EXR-processing applications and correlate them with recently ingested .exr files.
• Use software composition analysis and container scanning to locate OpenEXR across workstations, render nodes, servers, CI pipelines, and container images.
• Treat unexpected crashes during EXR decode as potential exploitation attempts and preserve the triggering file, process crash dump, and related logs for analysis.