CVE-2026-34380

What it actually does

A signed 32-bit integer overflow in OpenEXR's PXR24 decompression path can cause an incorrectly small size value to be used during bounds checking. When an application using vulnerable OpenEXR versions decodes a specially crafted EXR image with a large width value, the calculation for pixel output size may wrap before being cast to a 64-bit integer. If the wrapped value allows the bounds check to pass, the decoder can write pixel data beyond the allocated output buffer. The most likely outcomes are process crash, memory corruption, and denial of service; limited data corruption or unpredictable process behavior may also be possible depending on compiler, build options, allocator behavior, and how the library is embedded.

Why it matters to the business

Organizations that process EXR files—especially media pipelines, rendering farms, asset ingestion systems, image conversion services, visual-effects tooling, and applications that accept externally supplied image files—could experience crashes, failed jobs, corrupted processing output, or service disruption from a malicious or malformed EXR file. The CVSS score is moderate and EPSS is currently very low with no known KEV listing or public exploit maturity, but OpenEXR is commonly embedded in downstream graphics and media software, so exposure may exist indirectly through packaged applications rather than only through explicitly installed OpenEXR libraries.

How an attack unfolds

An attacker prepares a malformed EXR image that uses PXR24 compression and sets image dimensions so that the vulnerable width-based multiplication overflows during decoding. The file must then be delivered to a workflow or application that uses an affected OpenEXR version and processes attacker-controlled EXR content, such as upload, preview, render, conversion, thumbnail generation, or asset validation. When the vulnerable decoder reaches undo_pxr24_impl(), the overflow may cause the bounds check to use an incorrectly small value. If the crafted values align with the vulnerable build's arithmetic behavior, the decompression loop writes past the output buffer. In practical terms, exploitation is user- or workflow-assisted because a vulnerable application must parse the crafted file, and reliability is likely build-dependent; the expected attacker objective is denial of service or disruption of file-processing services rather than confirmed remote code execution.

How to fix it

Upgrade OpenEXR to a fixed release: 3.2.7 or later on the 3.2 branch, 3.3.9 or later on the 3.3 branch, or 3.4.9 or later on the 3.4 branch. Rebuild and redeploy any applications, plugins, containers, render nodes, media tools, or SDKs that statically or dynamically link vulnerable OpenEXR libraries. Because OpenEXR is often bundled into larger graphics applications, verify vendor advisories and update downstream packages even where OpenEXR is not installed as a standalone package. If immediate patching is not possible, restrict processing of untrusted EXR files, disable or isolate automated EXR ingestion where feasible, run image-processing workloads in sandboxed or low-privilege environments, enforce resource limits and crash isolation for render/conversion workers, and consider temporarily blocking PXR24-compressed EXR content from untrusted sources.

How to confirm the fix worked

Confirm the installed or bundled OpenEXR version is not in the vulnerable range: affected versions are 3.2.0 through before 3.2.7, 3.3.x before 3.3.9, and 3.4.x before 3.4.9. Validate both system packages and embedded copies in applications, containers, build artifacts, plugin directories, and statically linked binaries. Use package manager queries, software composition analysis, SBOMs, container image scans, and binary dependency inspection to identify libOpenEXR and OpenEXRCore versions. After upgrade, rerun representative EXR processing workflows and confirm that malformed or oversized PXR24 EXR files are rejected safely or do not crash the application. For high-assurance validation, run regression tests or fuzz tests with sanitizers enabled and verify there are no signed integer overflow, heap-buffer-overflow, or out-of-bounds write findings in the PXR24 decode path.

Typical attack path

1. Identify a target application, service, or pipeline that accepts or processes EXR image files using OpenEXR 3.2.0 through versions before 3.2.7, 3.3.9, or 3.4.9.
2. Craft an EXR file using PXR24 compression with dimensions that trigger signed integer overflow in the decoder's width calculation.
3. Submit or deliver the malformed EXR file through an upload feature, asset pipeline, render queue, shared project file, email attachment, repository, or other ingestion path.
4. Wait for the vulnerable OpenEXR-based component to decode the file.
5. Trigger out-of-bounds writes during decompression, causing memory corruption, process crash, failed processing jobs, or potentially unpredictable application behavior.

How to detect it

There are no widely reported exploitation campaigns or known actor-specific indicators for this issue, and successful exploitation may look like a normal file-processing crash unless detailed application and crash telemetry is available. Review logs from EXR ingestion services, render workers, image conversion tools, thumbnailers, asset management systems, and any application that processes EXR files. Look for crashes, abnormal exits, segmentation faults, heap corruption messages, sanitizer reports, or repeated worker restarts that occur immediately after handling EXR files, especially PXR24-compressed files from untrusted or newly created sources. Useful log sources include application logs, render farm/job scheduler logs, web upload logs, object storage access logs, EDR process telemetry, Linux journal/syslog, Windows Application Error Reporting events, container runtime logs, crash dumps, core dumps, and sanitizer/fuzzer output. In forensic review, correlate the timestamp of process crashes with recently ingested .exr files, preserve the triggering files for offline analysis, and inspect crash stacks for OpenEXRCore, internal_pxr24.c, or undo_pxr24_impl. Because exploitation is content-triggered, network IOCs are unlikely unless the delivery path is visible through upload logs or file transfer records.

• undo_pxr24_impl
• internal_pxr24.c
• OpenEXRCore
• libOpenEXRCore
• pxr24
• PXR24
• signed integer overflow
• heap-buffer-overflow
• buffer overflow
• out-of-bounds write
• Segmentation fault
• SIGSEGV
• .exr
• AddressSanitizer
• runtime error: signed integer overflow

What your security team should do

• Prioritize inventory of systems and applications that process EXR files, including media ingestion, rendering, conversion, preview, thumbnailing, and asset management workflows.
• Upgrade OpenEXR to 3.2.7, 3.3.9, 3.4.9, or later as appropriate, and ensure dependent applications are rebuilt or updated to use the fixed library.
• Ask vendors of graphics, visual-effects, rendering, image-processing, and content-management products whether they bundle a vulnerable OpenEXR release and obtain patched versions.
• Restrict untrusted EXR file ingestion until patching is complete, especially for internet-facing upload services and automated processing queues.
• Run EXR processing components with least privilege, sandboxing, memory safety hardening, process isolation, and job-level time/resource limits to reduce the impact of crashes or memory corruption.
• Search historical logs for unexplained crashes or sanitizer findings in OpenEXR PXR24 decoding, particularly following processing of externally supplied EXR files.
• Add file-processing telemetry that records EXR ingestion source, filename, job identifier, decoder errors, and crash correlation while avoiding storage of sensitive content.
• Monitor for future exploit publication because current EPSS and exploit maturity are low, but file-parser memory corruption bugs can become more relevant if proof-of-concept files are released.