CVE-2026-34588

What it actually does

OpenEXR versions 3.1.0 through versions before 3.2.7, 3.3.9, and 3.4.9 contain an integer overflow in the PIZ wavelet decompression path. The vulnerable internal_exr_undo_piz() routine advances an in-place working pointer using signed 32-bit arithmetic derived from image dimensions and channel-related counters. A malformed EXR file can cause the pointer calculation to wrap, making subsequent channel decoding read from and write to the wrong memory address. This can result in out-of-bounds reads, out-of-bounds writes, process crashes, memory corruption, and potentially arbitrary code execution in the context of the application processing the file.

Why it matters to the business

Systems that ingest, preview, convert, render, transcode, or validate EXR images may be crashed or potentially compromised by a crafted image file. This is especially relevant to media pipelines, VFX/render farms, asset-management platforms, content-submission portals, desktop creative tools, and automated file-processing services. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the vulnerability affects a widely used image-format library and should be prioritized anywhere EXR files are accepted from external users, partners, customers, or automated feeds.

How an attack unfolds

An attacker creates a malicious EXR image using PIZ compression and carefully chosen dimensions, channel layout, or compressed data characteristics that cause signed 32-bit arithmetic in the wavelet undo routine to overflow. The attacker then delivers the file to a target workflow, such as uploading it to an asset portal, sending it to a user, placing it in a watched folder, or submitting it to a render or conversion pipeline. When a vulnerable OpenEXR-based application parses the file, internal_exr_undo_piz() miscalculates the wavelet buffer pointer. The next channel decode then operates from an incorrect address, producing out-of-bounds reads and writes. Depending on memory layout and hardening, exploitation may result in denial of service through a crash, information exposure through invalid reads, or potential code execution within the privileges of the image-processing process.

How to fix it

Upgrade OpenEXR to a fixed release: 3.2.7, 3.3.9, 3.4.9, or any later version in the applicable branch. Rebuild and redeploy applications, plugins, containers, render workers, and desktop packages that statically or dynamically link OpenEXR. If immediate patching is not possible, reduce exposure by blocking or quarantining untrusted EXR uploads, disabling EXR/PIZ processing where feasible, processing files in hardened sandboxes, applying memory-safety mitigations, running image-processing services with least privilege, and isolating render or conversion workers from sensitive networks and data stores.

How to confirm the fix worked

Confirm the runtime and build-time OpenEXR version used by each application, not only the system package version. Validate that linked libraries resolve to OpenEXR 3.2.7, 3.3.9, 3.4.9, or later. Check package manifests, container images, SBOMs, plugin bundles, and statically linked binaries for vulnerable OpenEXR components. Exercise representative EXR parsing workflows after upgrade to ensure files still process correctly. Where available, use vulnerability scanners or software-composition-analysis tools to verify that OpenEXR versions 3.1.0 through pre-fixed 3.2.x, 3.3.x, and 3.4.x builds are no longer present.

Typical attack path

1. Identify an application, service, or pipeline that processes EXR files using a vulnerable OpenEXR version from 3.1.0 up to but not including 3.2.7, 3.3.9, or 3.4.9.
2. Craft an EXR file using PIZ compression with values that trigger signed 32-bit overflow in the wavelet pointer calculation.
3. Deliver the crafted file through an upload form, shared asset repository, email attachment, file drop, render queue, watched directory, or other content-ingestion path.
4. Wait for the vulnerable application or automated worker to parse or decode the EXR file.
5. Trigger memory corruption during in-place wavelet decoding, causing a crash or potentially gaining code execution in the context of the affected process.
6. Use any achieved execution to access files, pivot within the processing environment, tamper with rendered assets, or disrupt production workflows.

How to detect it

Review logs and telemetry from systems that parse EXR files, including upload services, media-processing APIs, render workers, asset-management systems, desktop crash reporters, EDR telemetry, container logs, and core-dump repositories. Look for crashes or abnormal exits during EXR decoding, especially involving PIZ compression, wavelet decompression, internal_exr_undo_piz(), segmentation faults, access violations, heap corruption, or sanitizer findings. Correlate crashes with recently submitted EXR files, repeated submissions from the same source, unusually large or malformed EXR dimensions, unexpected channel counts, and files that consistently crash multiple workers. Preserve suspect EXR samples, process command lines, core dumps, and memory-safety reports for triage. Because no public exploitation or KEV activity is currently reported, detection should focus on exploit attempts manifesting as parser crashes, malformed-file handling errors, and suspicious file-ingestion patterns rather than known actor-specific infrastructure.

• internal_exr_undo_piz
• undo_piz
• PIZ compression
• heap-buffer-overflow
• stack-buffer-overflow
• global-buffer-overflow
• out-of-bounds read
• out-of-bounds write
• signed integer overflow
• integer overflow
• AddressSanitizer
• runtime error: signed integer overflow
• Segmentation fault
• SIGSEGV
• access violation
• heap corruption
• EXR decode failed
• OpenEXR
• libOpenEXR
• libOpenEXRCore
• Imf_
• crafted EXR

What your security team should do

• Inventory all applications, services, containers, plugins, and workstations that process EXR files or include OpenEXR.
• Prioritize remediation for internet-facing upload services, partner-facing asset portals, automated render/conversion workers, and any workflow that processes untrusted EXR content.
• Upgrade OpenEXR to 3.2.7, 3.3.9, 3.4.9, or later, and rebuild dependent software to ensure the patched library is actually in use.
• Temporarily restrict EXR uploads or require pre-processing quarantine for untrusted EXR files until patching is complete.
• Run EXR processing in sandboxed, low-privilege worker processes with filesystem, network, and credential isolation.
• Search historical crash telemetry, application logs, EDR events, and core dumps for evidence of crashes in OpenEXR PIZ decompression routines.
• Add detection for suspicious or repeated EXR-processing crashes, especially where the same source repeatedly submits EXR files that crash workers.
• Update SBOM and dependency-monitoring rules so future OpenEXR regressions are identified quickly.