CVE-2026-42217

What it actually does

OpenEXR versions 3.0.0 through 3.2.8, 3.3.0 through 3.3.10, and 3.4.0 through 3.4.10 incorrectly decode variable-length integers from untrusted EXR files. A malicious EXR can include enough continuation bytes to make readVariableLengthInteger() perform an out-of-range left shift on a 64-bit value, which is undefined behavior in C/C++. Depending on compiler, build flags, platform, and calling application behavior, this may result in process crashes, incorrect parsing decisions, or other unpredictable behavior during image ingestion or conversion. The issue is most relevant to applications, render pipelines, media processing services, asset upload systems, thumbnailers, and batch converters that automatically parse EXR content from untrusted or semi-trusted sources.

Why it matters to the business

Organizations that accept, render, convert, scan, index, or preview EXR files may be exposed to disruption from crafted image files. In production media, visual effects, content management, and automated processing pipelines, exploitation could cause failed jobs, service instability, or interruption of asset-processing workflows. The vulnerability currently has low observed exploitation likelihood based on the provided EPSS score and is not listed in CISA KEV, but the high CVSS score and unauthenticated file-processing nature make timely remediation important for internet-facing or automated upload workflows.

How an attack unfolds

An attacker creates a malformed EXR file containing an intentionally overlong variable-length integer encoding. The attacker then gets a vulnerable OpenEXR-consuming application to parse that file, for example by uploading it to a media service, submitting it to an asset pipeline, sending it to a user or partner workflow that auto-generates previews, or placing it where an automated scanner or converter will process it. When the vulnerable OpenEXR library decodes the crafted integer, repeated continuation bytes cause the shift count to exceed the valid range for a 64-bit value. The resulting undefined behavior can crash the process or cause unpredictable parsing behavior. There is no public exploit maturity indicated in the input and no KEV listing, so defenders should treat this primarily as a high-severity parser hardening issue while still reviewing exposed file-processing paths for prior malformed EXR submissions.

How to fix it

Upgrade OpenEXR to a patched release in the active version line in use: 3.2.9 or later for the 3.2.x line, 3.3.11 or later for the 3.3.x line, or 3.4.11 or later for the 3.4.x line. If OpenEXR is bundled inside another application, SDK, container image, render tool, image converter, or operating system package, update the containing product or rebuild it against a patched OpenEXR library. Where immediate upgrade is not possible, reduce exposure by blocking untrusted EXR uploads, disabling EXR preview/thumbnail generation for untrusted content, isolating image-processing workers in sandboxed containers, enforcing CPU and memory limits, and routing EXR processing through patched validation services only.

How to confirm the fix worked

Confirm installed and bundled OpenEXR versions are not in the vulnerable ranges: 3.0.0-3.2.8, 3.3.0-3.3.10, or 3.4.0-3.4.10. Validate both system packages and statically or vendored copies inside applications, containers, plugins, and build artifacts. Run dependency and container scans for OpenEXR/libOpenEXR packages, then verify runtime linkage with package-manager output, software bill of materials data, or binary inspection. In test environments, process malformed EXR regression samples or vendor-provided tests and confirm the application rejects the file cleanly without undefined-behavior sanitizer findings, crashes, or worker restarts. Review upload and processing controls to confirm untrusted EXR files are either blocked or processed only by patched components.

Typical attack path

1. Identify an application, service, or workflow that accepts or automatically processes EXR files using OpenEXR.
2. Craft an EXR file with an overlong variable-length integer encoding that forces excessive continuation-byte decoding.
3. Deliver the file through an upload form, API, shared asset repository, email/workflow handoff, or batch-processing input location.
4. Wait for the vulnerable application or worker process to parse the EXR file.
5. Trigger undefined behavior in readVariableLengthInteger(), potentially causing a crash, failed job, or abnormal processing result.
6. Optionally repeat submissions to cause recurring disruption in automated media or rendering pipelines.

How to detect it

To assess prior exploitation, review logs from file-upload services, media-processing workers, render farms, image converters, thumbnail generators, content scanners, and crash-reporting systems for malformed EXR submissions followed by process crashes, worker restarts, failed conversion jobs, sanitizer findings, or abnormal parser errors. Focus on events involving externally supplied .exr files, repeated failures from the same source, unusually small or malformed EXR files, and failures occurring shortly after file ingestion. Examine application crash dumps and core files for stack traces involving OpenEXR variable-length integer decoding, especially readVariableLengthInteger(). If sanitizer builds are used in testing or production canaries, search for undefined-behavior reports mentioning excessive shift exponents. Network and web logs may show EXR uploads or API requests immediately preceding service errors, HTTP 5xx responses, queue retries, or worker termination events. No widely known threat actors or ransomware campaigns are identified in the provided input, and no KEV listing is present, so detection should emphasize anomalous malformed-file processing rather than known campaign infrastructure.

• readVariableLengthInteger
• shift exponent 70 is too large
• shift exponent is too large for 64-bit type
• runtime error: shift exponent
• UndefinedBehaviorSanitizer
• UBSan
• OpenEXR
• libOpenEXR
• Imf
• malformed EXR
• .exr
• EXR parse error
• EXR read error
• OpenEXR exception
• core dumped
• Segmentation fault

What your security team should do

• Inventory applications, media pipelines, render tools, converters, thumbnailers, scanners, and containers that include or link against OpenEXR.
• Prioritize patching any internet-facing, API-driven, or automated file-processing service that accepts EXR files from external users or partners.
• Upgrade OpenEXR to 3.2.9, 3.3.11, 3.4.11, or a later patched release, depending on the maintained branch in use.
• Check for vendored or statically linked OpenEXR copies in commercial tools, plugins, and internal applications, not only operating system packages.
• Temporarily restrict EXR uploads or disable automated EXR parsing for untrusted files until patching is complete.
• Run image-processing workloads with sandboxing, least privilege, resource limits, and crash isolation to reduce operational impact from malformed files.
• Search historical logs for crashes, sanitizer messages, repeated EXR parsing failures, or suspicious EXR uploads around the publication date and afterward.
• Add regression tests or fuzzing coverage for malformed EXR inputs in applications that directly expose OpenEXR parsing.