CVE-2026-42216

What it actually does

CVE-2026-42216 is an out-of-bounds read in OpenEXR's IDManifest::init() string reconstruction logic. When parsing a prefix-compressed string list, the parser assumes that a string following a previous string longer than 255 bytes contains at least two bytes for the prefix length, but it reads stringList[i][0] and stringList[i][1] without first validating the current string length. A malformed EXR file can therefore cause the library to read beyond the available buffer, potentially disclosing adjacent process memory to the parsing context or causing a crash/denial of service in applications, services, render pipelines, asset processors, or media tools that ingest untrusted EXR content.

Why it matters to the business

Organizations that process EXR images from users, partners, production pipelines, render farms, content repositories, or automated media workflows may be exposed to crashes or unintended memory disclosure when malformed files are processed. The operational risk is highest for internet-facing or automated file-ingestion services because exploitation can be triggered by supplying a crafted image file. Although EPSS is currently low and there is no CISA KEV listing or known ransomware association, the CVSS severity is high because exploitation requires no privileges and can affect confidentiality and availability in systems that parse EXR files.

How an attack unfolds

An attacker crafts an EXR file containing an ID manifest with a prefix-compressed string sequence where one reconstructed previous string exceeds 255 bytes and the following encoded string is shorter than the two bytes the parser expects for the prefix length. The attacker then delivers the file to an application or service that uses a vulnerable OpenEXR version to inspect, convert, render, thumbnail, transcode, validate, or otherwise parse EXR content. When the vulnerable parser reaches IDManifest::init(), it reads two bytes from a string buffer without verifying that those bytes exist. Depending on allocator layout, compiler hardening, and how the calling application handles parser output or crashes, this can result in process termination, service instability, or exposure of adjacent memory contents within the parsing process. No public exploit maturity or active exploitation is reported in the supplied data, but any automated EXR processing path should be treated as a potential attack surface.

How to fix it

Upgrade OpenEXR to a patched release: 3.2.9, 3.3.11, or 3.4.11, depending on the maintained branch in use. If OpenEXR is bundled into an application, rebuild or obtain an updated application package that incorporates one of those fixed library versions. Also update container images, render nodes, desktop imaging tools, media-processing services, CI pipelines, and language bindings or downstream packages that statically link or vendor OpenEXR. If immediate patching is not possible, restrict EXR ingestion to trusted sources, disable automated processing of untrusted EXR files, isolate file-processing workers with sandboxing and least privilege, enforce memory-safe crash containment, and limit network/API exposure for services that parse EXR content.

How to confirm the fix worked

Confirm all deployed OpenEXR runtime and development packages report a fixed version: 3.2.9 or later on the 3.2 branch, 3.3.11 or later on the 3.3 branch, or 3.4.11 or later on the 3.4 branch. Inventory both dynamically linked libraries and statically linked/vendor copies inside applications and containers. Use package-manager queries, software composition analysis, container image scans, and binary inspection to identify vulnerable versions. Where safe and authorized, validate with a regression test or vendor-provided proof file that exercises malformed ID manifest parsing and confirm the patched parser rejects the file or handles it without out-of-bounds reads, sanitizer findings, or crashes. Monitor crash telemetry after patching to ensure EXR-related parser faults cease.

Typical attack path

1. Identify an application, API, media pipeline, render worker, asset-management system, or content-processing service that accepts or retrieves EXR files.
2. Determine or assume that the target uses OpenEXR versions 3.0.0 through before 3.2.9, 3.3.0 through before 3.3.11, or 3.4.0 through before 3.4.11.
3. Create a malformed EXR file with an ID manifest string list that causes the vulnerable prefix-length parsing condition.
4. Submit, upload, email, synchronize, or otherwise place the crafted EXR file where the vulnerable parser will process it.
5. Trigger parsing through thumbnail generation, metadata extraction, validation, rendering, conversion, indexing, or import workflow.
6. Cause an out-of-bounds read that may crash the process or expose unintended process memory depending on the consuming application.

How to detect it

To assess possible prior exploitation, review telemetry from systems that parse EXR files, especially upload services, render workers, thumbnailers, content-indexing jobs, conversion services, and asset pipelines. Look for crashes, abnormal exits, worker restarts, core dumps, memory-sanitizer findings, or application exceptions that occur immediately after processing EXR files from untrusted or newly introduced sources. Useful log sources include application logs, web/API upload logs, file-processing queue logs, render farm job logs, endpoint detection telemetry, container orchestration restart events, systemd/journald logs, crash reporters, core dump directories, and object-storage or content-repository access logs. Correlate timestamps of EXR ingestion with segmentation faults, heap-buffer-overflow reports, out-of-bounds read findings, or stack traces referencing IDManifest::init. Because the vulnerability is triggered through malformed file content and no unique exploit payload is provided, absence of these artifacts does not prove absence of attempted exploitation.

• IDManifest::init()
• IDManifest::init
• heap-buffer-overflow
• out-of-bounds read
• SEGV
• SIGSEGV
• segmentation fault
• OpenEXR
• ImfIDManifest

What your security team should do

• Prioritize patching internet-facing, partner-facing, or automated file-ingestion systems that process EXR files before lower-risk desktop-only tooling.
• Inventory all uses of OpenEXR, including embedded copies in media software, render pipelines, asset-management platforms, containers, and statically linked binaries.
• Upgrade to OpenEXR 3.2.9, 3.3.11, or 3.4.11 as applicable, and verify downstream applications have incorporated the fixed library.
• Temporarily restrict or sandbox processing of untrusted EXR files until all affected systems are updated.
• Add monitoring for crashes or sanitizer reports involving IDManifest::init() or EXR parsing in services that accept external media files.
• Review recent EXR uploads or externally sourced EXR files if unexplained crashes occurred in image-processing services.
• Because there is no KEV listing, no known ransomware use, and low EPSS at the time of this intelligence, treat this as high-severity exposure requiring planned urgent remediation rather than confirmed active mass exploitation.