CVE-2026-88384

What it actually does

OpenEXR 3.4.14 has a NULL pointer dereference in the C++ attribute-parsing path. An EXR file that includes an unknown-type attribute with dataSize set to zero causes the parser to construct an OpaqueAttribute whose packed_data pointer is NULL; the constructor then passes that pointer to memcpy() without treating the zero-size case as valid, producing undefined behavior and typically aborting the host process. Per the CVSS vector this is a local, user-interaction-required availability failure only: no confidentiality or integrity impact is indicated, and there is no evidence of reliable code execution from this defect.

Why it matters to the business

Studios, render farms, DAM systems, and any product that opens OpenEXR assets can lose the parsing process or service when a malicious or malformed EXR is opened, interrupting artist workstations and automated ingest or transcode jobs until the process is restarted. The issue is 13 days old, is not in CISA KEV, is not associated with ransomware, and has no known exploit maturity, so widespread opportunistic attacks are unlikely—but pipelines that automatically open untrusted .exr files still face a practical denial-of-service risk. No downstream package counts or vendor fixed-version list were supplied, so exposure depends on wherever OpenEXR 3.4.14 (or an equivalent unpatched build) is linked.

How an attack unfolds

An attacker prepares an OpenEXR file whose attribute table contains an unknown type with a zero dataSize, so the C++ parser allocates an opaque attribute with a NULL packed_data pointer. The file is delivered as an attachment, a download, a shared production asset, or a drop into a watch folder. When a user or an automated job opens it with a binary linked to the vulnerable OpenEXR 3.4.14 parser, OpaqueAttribute’s constructor calls memcpy() on the NULL pointer, the process crashes, and that application or pipeline stage becomes unavailable. No named threat actors or in-the-wild campaigns are reported, and the required user (or ingest) interaction plus local file parse limit this to targeted disruption rather than unauthenticated remote takeover.

How to fix it

Inventory every runtime that ships or dynamically links OpenEXR 3.4.14 (applications, DCC tools, render nodes, transcoders, and language bindings). Apply the vendor or distro patch as soon as a build newer than 3.4.14 that hardens OpaqueAttribute / unknown-attribute handling is published; no exact fixed-version list was provided with this record, so follow Academy Software Foundation / OpenEXR and OS package advisories rather than assuming a version number. Until patched, do not open untrusted EXR files on production hosts, disable automatic ingest of .exr from untrusted sources, run parsers in a crash-isolated worker with tight file-type and size limits, and prefer processes that use a patched or alternative image stack. Rebuild and redeploy statically linked binaries after upgrading the library.

How to confirm the fix worked

Confirm the loaded OpenEXR shared library or statically linked version is not 3.4.14 (package manager, SBOM, ldd/otool, or the library’s version API). After upgrading, regression-test normal EXR open/save paths in a non-production harness using vendor or project test assets—not a live production queue. Verify that unknown attributes and zero-length payloads are rejected or handled without process abort, and that crash-monitoring for OpenEXR-linked binaries stays quiet. Re-scan container images and vendor DCC installers so leftover 3.4.14 copies are not still on PATH.

Typical attack path

1. Attacker crafts an EXR whose header includes an unknown-type attribute with dataSize equal to zero
2. Attacker delivers the file via email, cloud share, marketplace, or a content-ingest location that production tools consume
3. A user or automated OpenEXR-linked application opens or parses the file
4. The C++ attribute parser builds an OpaqueAttribute with a NULL packed_data pointer
5. memcpy() is invoked on that NULL pointer, the process terminates, and the affected viewer, converter, or render stage is denied service

How to detect it

There is no public exploit maturity and no named actor activity, so hunt for effects rather than a known payload. On endpoints and render nodes, look for abnormal exits (SIGSEGV/SIGABRT) of viewers, converters, compositors, or render workers immediately after an .exr open; inspect core dumps and symbolized stacks for OpenEXR attribute parsing, OpaqueAttribute, and memcpy. Correlate with file-creation or mail/download events for .exr files from untrusted sources. Review application logs around IlmImf/OpenEXR load and any worker-pool restart storms. Absence of these artifacts does not prove the library was never invoked; it only means a crash may not have been recorded.

• OpenEXR 3.4.14
• libOpenEXR-3_4
• libOpenEXR.so
• IlmImf
• OpaqueAttribute
• packed_data
• SIGSEGV
• SIGABRT
• .exr
• 76 2f 31 01

What your security team should do

• Prioritize an SBOM and runtime inventory of OpenEXR 3.4.14 in DCC tools, render farms, and media ingest services
• Patch or rebuild as soon as an upstream or distro fix newer than 3.4.14 is available; this is not KEV but availability impact on production pipelines is real
• Until patched, block or quarantine untrusted .exr ingest and isolate EXR parsers in disposable workers
• Add crash alerting for OpenEXR-linked processes (segfault/abort on file open) and treat clusters of crashes after .exr receipt as suspected abuse
• Track Academy Software Foundation / OpenEXR advisories for the official fixed release, then verify no leftover 3.4.14 libraries remain