CVE-2026-55371 Overview
CVE-2026-55371 is a NULL pointer dereference vulnerability in OpenEXR, the reference implementation of the EXR high-dynamic-range image file format used extensively in motion picture production. The flaw resides in the exr_attr_set_bytes() function within OpenEXRCore. Versions 3.4.0 through 3.4.12 are affected, and version 3.4.13 contains the fix. Successful exploitation causes a deterministic process crash, resulting in denial of service for any application linking the vulnerable OpenEXRCore C API. The issue is tracked under [CWE-20] Improper Input Validation.
Critical Impact
A caller passing a positive hint_length alongside a NULL type_hint pointer triggers a guaranteed crash through the public OpenEXRCore C API.
Affected Products
- OpenEXR 3.4.0 through 3.4.12 (OpenEXRCore component)
- Applications and libraries linking the OpenEXRCore C API
- Motion picture and imaging pipelines that process untrusted EXR attribute data
Discovery Timeline
- 2026-08-25 - CVE-2026-55371 published to NVD
- 2026-08-25 - Last updated in NVD database
Technical Details for CVE-2026-55371
Vulnerability Analysis
The vulnerability is a NULL pointer dereference reachable through the public OpenEXRCore C API. The exr_attr_set_bytes() setter validates the top-level exr_attr_bytes_t value pointer but fails to verify that the nested type_hint pointer is non-NULL when hint_length is greater than zero. When a caller supplies a positive hint_length together with a NULL type_hint, the internal exr_attr_bytes_create() function allocates a destination type-hint buffer and then attempts to copy from the NULL source pointer. The resulting dereference terminates the process. Because the trigger condition is deterministic and depends only on caller-controlled parameters, any application forwarding untrusted attribute data to this API can be crashed reliably.
Root Cause
The root cause is missing input validation on a nested pointer field. The setter treats hint_length as authoritative and does not enforce the invariant that a non-zero length must be paired with a non-NULL source buffer before invoking the internal copy routine.
Attack Vector
Exploitation requires local access to invoke the OpenEXRCore API with attacker-influenced attribute values. An attacker who can supply crafted EXR attribute data to a process that calls exr_attr_set_bytes() can force a crash. Impact is limited to availability; there is no confidentiality or integrity impact and no code execution primitive.
See the OpenEXR GitHub Security Advisory GHSA-xx72-f24p-cf6r for maintainer analysis.
Detection Methods for CVE-2026-55371
Indicators of Compromise
- Unexpected SIGSEGV or access-violation crashes in processes linking libOpenEXRCore or libOpenEXR
- Crash stack traces referencing exr_attr_set_bytes or exr_attr_bytes_create
- Repeated application termination when processing specific EXR files or attribute payloads
Detection Strategies
- Inventory installed OpenEXR versions across build systems, render farms, and media pipelines to identify releases in the 3.4.0–3.4.12 range.
- Enable core dump collection on services that parse EXR data and inspect faulting addresses for NULL dereferences inside OpenEXRCore frames.
- Fuzz-test EXR ingestion paths with attribute payloads that pair non-zero lengths with NULL pointer fields to surface latent callers of the vulnerable API.
Monitoring Recommendations
- Monitor process crash telemetry from workstations and render nodes that handle EXR content.
- Alert on abnormal restart rates for imaging services, compositors, and rendering daemons.
- Track software bill of materials (SBOM) entries for OpenEXR to detect vulnerable versions reintroduced through dependency updates.
How to Mitigate CVE-2026-55371
Immediate Actions Required
- Upgrade OpenEXR to version 3.4.13 or later on all systems that link OpenEXRCore.
- Rebuild and redeploy downstream applications, plugins, and container images that statically or dynamically bundle OpenEXR.
- Restrict processing of untrusted EXR files to sandboxed or isolated environments until patching is complete.
Patch Information
The issue is fixed in OpenEXR version 3.4.13. Refer to the OpenEXR GitHub Security Advisory GHSA-xx72-f24p-cf6r for release details and commit references.
Workarounds
- In application code, validate that type_hint is non-NULL whenever hint_length is greater than zero before calling exr_attr_set_bytes().
- Reject or sanitize EXR attribute inputs originating from untrusted sources at the application boundary.
- Isolate EXR parsing workloads in restart-tolerant workers so a crash does not disrupt the parent service.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
