OpenEXR 3.4.14 fixes 15 vulnerabilities in a format trusted by visual pipelines

The Academy Software Foundation released OpenEXR 3.4.14 on August 7 with fixes for 15 CVEs and broader audit and fuzzing hardening. The documented attack path is a malicious or malformed .exr file opened through the OpenEXR or OpenEXRUtil C++ libraries, command-line tools or PyOpenEXR.

The fixed classes include heap-buffer overflows, out-of-bounds reads and writes, integer overflows and malformed-metadata crashes. Consequences can include denial of service, information disclosure and, in the worst case, arbitrary code execution. Some integer-overflow findings apply specifically to 32-bit or ILP32 builds rather than typical 64-bit desktops and servers. PyOpenEXR’s RGB channel-coalescing issues affect the default separate_channels=False path. The release also rejects truncated compressed streams and oversized allocations, adds null checks and updates OpenJPH to 0.31.0.

An image format can be part of the attack surface. Studios that ingest EXR sequences from clients, vendors or public transfers should treat decoder hygiene like any other supply-chain control: isolate untrusted media, keep tools patched and avoid assuming that a familiar extension is safe. The risk is operational, not a reason to abandon EXR.

The upstream library is available without usage credits or regional limits, but many editing, compositing and rendering applications bundle their own OpenEXR version. We are watching vendor advisories and application updates rather than assuming that installing 3.4.14 separately patches DaVinci Resolve, Nuke, Adobe tools or other packaged software.