CVE-2026-34543

What it actually does

OpenEXR versions 3.4.0 through 3.4.7 can leak sensitive heap memory into decoded pixel data when parsing a malicious EXR image. The issue is triggered under default settings by reading the crafted file. No authentication, special configuration, or user interaction is required when the vulnerable parser is exposed through an automated image-processing workflow. The flaw does not directly allow code execution or data modification, but it can disclose process memory that may contain image data, file contents, credentials, tokens, paths, or other transient secrets depending on what the consuming application keeps in memory.

Why it matters to the business

Organizations that process EXR files may unintentionally disclose sensitive data from rendering, media, design, visual effects, or automated asset pipelines. The greatest risk is in services that accept EXR files from external or semi-trusted sources and return, store, or transmit decoded image output, because an attacker may be able to recover memory contents from the service. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low, stable EPSS score, but the low-complexity trigger means internet-facing or partner-facing file ingestion systems should still be prioritized.

How an attack unfolds

An attacker creates a specially malformed EXR file designed to trigger the heap-memory disclosure during decoding. They then deliver the file to an application, service, render farm, content pipeline, asset management system, preview generator, or conversion tool that uses a vulnerable OpenEXR version. When the system reads the file, OpenEXR decodes image data incorrectly and copies bytes from heap memory into the resulting pixel data. If the application returns the decoded image, generates a preview, writes converted output, stores the processed pixels, or otherwise exposes the decoded result, the attacker retrieves that output and analyzes the pixel data for leaked memory fragments. Repeated submissions may increase the chance of recovering useful secrets, especially from long-running worker processes handling multiple jobs or users.

How to fix it

Upgrade OpenEXR to version 3.4.8 or later wherever OpenEXR is used directly or bundled into applications, containers, render nodes, image-processing services, desktop tools, and media pipelines. If packaged fixed-version metadata is unavailable from a vendor, verify the bundled OpenEXR library version explicitly rather than relying only on application version numbers. Rebuild statically linked software and container images that include vulnerable OpenEXR code. As interim mitigations, restrict EXR ingestion to trusted sources, isolate image parsing in sandboxed worker processes, clear or rotate worker processes between untrusted jobs, limit what decoded output is returned to users, and disable externally supplied EXR processing where it is not required.

How to confirm the fix worked

Confirm that all deployed OpenEXR instances report version 3.4.8 or later, including command-line tools, shared libraries, application bundles, containers, and statically linked dependencies. Use software composition analysis, package inventory, container scanning, and runtime checks such as package manager queries or library version inspection. Validate that externally reachable upload, preview, conversion, render, and asset-processing paths no longer use OpenEXR 3.4.0 through 3.4.7. Where practical, test with a controlled regression case from the vendor or upstream project and confirm that decoding no longer produces unintended heap-derived pixel output. Also verify that mitigations are enforced for systems that cannot be immediately upgraded, such as file-type restrictions, sandboxing, and isolation of untrusted parsing workloads.

Typical attack path

1. Identify an application or automated workflow that accepts or processes EXR image files.
2. Craft or obtain a malicious EXR file that triggers the OpenEXR heap information disclosure.
3. Submit the EXR file to the vulnerable service, pipeline, or tool.
4. Cause the service to decode, preview, transform, render, or otherwise process the file using OpenEXR 3.4.0 through 3.4.7.
5. Retrieve the decoded image, preview, converted file, stored artifact, or response containing pixel data.
6. Extract and inspect anomalous pixel bytes for leaked heap memory contents such as tokens, paths, fragments of other files, or sensitive application data.
7. Repeat the process to collect additional memory fragments if the workflow allows repeated file submissions.

How to detect it

There are no widely reported public exploitation indicators or known threat actors associated with this issue, and generic exploitation may not leave distinctive traces beyond normal EXR processing activity. To assess possible prior exploitation, review file upload, object storage, render-farm, media pipeline, preview-generation, and image-conversion logs for EXR files submitted to systems running OpenEXR 3.4.0 through 3.4.7. Focus on untrusted or anonymous sources, repeated EXR submissions, unusually small or malformed EXR files, failed or anomalous decode attempts, and workflows where the requester could retrieve decoded output. Examine generated previews, converted images, cached pixel buffers, and response artifacts for unexpected high-entropy or non-image-like pixel data that may represent heap fragments. Correlate submissions with outbound downloads or API responses by the same source shortly after processing. For forensic review, preserve suspicious input files, generated outputs, worker logs, application access logs, object-store access records, and container or host images where feasible. Because this is an information disclosure bug rather than code execution, endpoint telemetry may not show new processes, persistence, or command execution.

What your security team should do

• Inventory all applications, containers, render workers, media-processing services, and desktop tools that include OpenEXR.
• Prioritize upgrade or containment for systems that accept EXR files from the internet, customers, partners, contractors, or other untrusted sources.
• Upgrade vulnerable OpenEXR deployments to version 3.4.8 or later and rebuild any statically linked applications or container images.
• Ask vendors of image, rendering, VFX, asset-management, and conversion products to confirm whether they bundle vulnerable OpenEXR versions and provide patched builds.
• Temporarily restrict EXR uploads or route them through sandboxed, short-lived workers until all affected systems are patched.
• Review historical EXR submissions and processing outputs for suspicious activity if vulnerable systems exposed decoded results to submitters.
• Add dependency monitoring so future OpenEXR advisories are detected across both operating-system packages and embedded application dependencies.