CVE-2026-34544

What it actually does

CVE-2026-34544 is a memory corruption vulnerability in OpenEXR versions 3.4.0 through 3.4.7. A specially crafted EXR image using B44 or B44A compression can trigger an out-of-bounds write when decoded through exr_decoding_run(). The most likely result is a process crash, but depending on heap layout and allocator behavior, adjacent heap memory may be corrupted, potentially affecting confidentiality, integrity, and availability within the decoding process. Exploitation requires a vulnerable application to open, preview, ingest, render, transcode, or otherwise decode a malicious EXR file.

Why it matters to the business

Organizations that process EXR images in media pipelines, rendering farms, asset management systems, visual effects workflows, image conversion services, or desktop creative applications could experience application crashes, failed batch jobs, interrupted production workflows, or potentially deeper compromise of systems that automatically process untrusted files. Although EPSS is currently low at 0.00244 with no observed 30-day increase, the affected component is a widely reused image-format library, so exposure may exist indirectly through applications that bundle or dynamically link OpenEXR. The issue is not currently listed in CISA KEV and is not known to be used in ransomware campaigns, but remediation is still important for systems that accept EXR files from external or semi-trusted sources.

How an attack unfolds

An attacker creates a malformed EXR image that uses B44 or B44A compression and is structured to trigger an out-of-bounds write during decoding. The attacker then convinces a user to open the file or submits it to an automated workflow such as upload, preview generation, media ingestion, rendering, thumbnailing, or transcoding. When a vulnerable application using OpenEXR 3.4.0 through 3.4.7 calls exr_decoding_run(), the malformed data causes memory to be written outside the intended buffer. In the common case, this terminates the process and causes a denial of service. In a more favorable memory layout for the attacker, heap corruption could alter adjacent allocations and create a path toward more serious process manipulation, though no public exploit maturity is currently reported.

How to fix it

Upgrade OpenEXR to version 3.4.8 or later wherever OpenEXR 3.4.0 through 3.4.7 is installed, embedded, statically linked, or bundled in dependent applications. Rebuild applications that statically link OpenEXR so they include the patched decoder. For dynamically linked deployments, ensure runtime library paths resolve to the patched OpenEXR version. Where immediate upgrade is not possible, reduce exposure by blocking or quarantining untrusted EXR files, disabling automated EXR preview/thumbnail/transcode processing for untrusted sources, isolating media-processing workloads in sandboxes or containers, and enforcing least privilege on render and ingestion services.

How to confirm the fix worked

Confirm the installed or bundled OpenEXR version is 3.4.8 or later. Inventory both system packages and application-bundled copies because media, rendering, and creative software may ship private OpenEXR libraries. Validate dynamic linking with package-manager queries, software bills of materials, binary inspection, or runtime dependency checks. Re-run application test cases that decode B44 and B44A EXR files to confirm normal functionality after upgrade. For exposed file-processing services, verify that untrusted EXR uploads are either processed by patched components or blocked/sandboxed until patched.

Typical attack path

1. Identify an application, service, or workflow that accepts or processes EXR image files.
2. Craft an EXR file using B44 or B44A compression with malformed data intended to trigger the decoder flaw.
3. Deliver the file through email, file upload, shared asset repository, render job submission, content ingestion, or another file-processing path.
4. Cause a vulnerable OpenEXR 3.4.0 through 3.4.7 decoder to process the malicious file via exr_decoding_run().
5. Trigger an out-of-bounds write during decoding.
6. Achieve process crash, workflow disruption, or potentially heap corruption depending on runtime conditions.

How to detect it

To determine whether exploitation may have occurred, review logs from applications, render workers, asset ingestion systems, image conversion services, thumbnail generators, and desktop crash-reporting tools that process EXR files. Look for crashes, segmentation faults, heap corruption errors, aborts, or repeated job failures occurring immediately after EXR file handling, especially files using B44 or B44A compression. Useful log sources include application logs, worker/job scheduler logs, upload and content-ingestion logs, endpoint detection telemetry, operating-system crash dumps, core dump metadata, Windows Error Reporting, macOS crash reports, Linux systemd journal entries, container logs, and sanitizer/allocator diagnostics if enabled. Investigate recently uploaded or opened EXR files associated with crashes, preserve samples for offline analysis, and inspect whether call stacks include OpenEXR decoding functions such as exr_decoding_run(). Because this vulnerability is file-triggered and no public exploitation campaign is reported, detection is primarily based on crash correlation and suspicious EXR file provenance rather than network indicators.

• exr_decoding_run
• B44_COMPRESSION
• B44A_COMPRESSION
• B44 compression
• B44A compression
• OpenEXR
• Segmentation fault
• heap corruption
• out-of-bounds write
• corrupted size vs. prev_size
• malloc(): corrupted top size
• double free or corruption
• EXCEPTION_ACCESS_VIOLATION
• .exr

What your security team should do

• Prioritize patching systems and applications that automatically process EXR files from external users, partners, public uploads, or shared production repositories.
• Upgrade OpenEXR to 3.4.8 or later and rebuild any applications that statically link vulnerable OpenEXR versions.
• Inventory downstream applications that bundle OpenEXR rather than relying only on operating-system package versions.
• Temporarily restrict B44 and B44A EXR processing from untrusted sources where patching cannot be completed quickly.
• Run media-processing services with sandboxing, memory-safety hardening, low privileges, and crash isolation to limit impact from malformed files.
• Monitor crash logs and ingestion failures for OpenEXR decoder crashes involving B44 or B44A compressed files.
• Because EPSS is currently low and no KEV listing exists, treat this as risk-based remediation, with higher urgency for internet-facing or partner-facing file ingestion workflows.