v3.4.14

v3.4.14 is a security-focused patch release. It fixes 15 CVEs plus a broad set of additional hardening changes uncovered by the same fuzzing/audit effort.

For each of these vulnerabilities, an attacker's vector is a maliciously crafted .exr file that must be opened by a victim, whether through the OpenEXR/OpenEXRUtil C++ libraries, the command-line tools (exrmetrics, exrmultiview, exrmultipart), or the PyOpenEXR Python bindings. The primary flaw for most of the CVEs is memory corruption — heap buffer overflows and out-of-bounds reads/writes — which at minimum crashes the reading process (denial of service) and in several cases could plausibly be leveraged for information disclosure or, in the worst cases, arbitrary code execution.

No user interaction beyond opening the file is required, so any pipeline, service, or application that decodes untrusted or third-party EXR files should treat this as a priority upgrade. Severity generally ranges from moderate (crash-only, or requiring an uncommon build configuration) to high (heap overflow reachable with a small, easily-crafted file on common configurations).

The individual vulnerabilities fall into four broad groups:

• PyOpenEXR RGB-channel-coalescing bugs (CVE-2026-68514, CVE-2026-68513, CVE-2026-62986, CVE-2026-61703). When the Python bindings combine per-channel data (e.g. left.R, left.G, left.B) into a single coalesced RGB array, conflicting or mismatched channel names/types were not fully validated, which could undersize the destination NumPy buffer. The result is a heap buffer overflow on read, or, in the deep-image case, disclosure of uninitialized ("stale") heap memory through the returned array. This affects only code paths that read files with separate_channels=False (the default for RGB coalescing).

• Integer-overflow-driven heap overflows on 32-bit (ILP32) builds (CVE-2026-59985
  CVE-2026-59984, CVE-2026-59983, CVE-2026-59982, CVE-2026-59981, CVE-2026-59189, CVE-2026-59186). On platforms where size_t/int are 32 bits, buffer sizes computed from attacker-controlled header fields (dimensions, sample counts, tile sizes) could overflow before an allocation or bounds check, yielding an undersized buffer and a subsequent heap out-of-bounds read or write during RLE, B44/B44A, or DWAA decompression, deep sample-count-table decoding, or large-tile handling. These do not affect typical 64-bit desktop/server builds, but are significant for 32-bit Linux, embedded, and some mobile/CI targets.

• Heap out-of-bounds access in OpenEXRUtil and the command-line
  tools with non-default data windows (CVE-2026-59981, CVE-2026-59189, CVE-2026-59187, CVE-2026-59186, CVE-2026-59184). FlatImageChannel/DeepImageChannel/SampleCountChannel row addressing, and the deep-pixel path in exrmetrics, assumed a data window originating at (0, 0). Crafted files with a nonzero data window origin, or subsampled channels, caused row-address computations to land outside the allocated buffer, producing a heap read or write out of bounds.

• Crashes from malformed metadata (denial of service) (CVE-2026-61555, CVE-2026-59183). An empty multiView attribute could crash viewFromChannelName(), and a signed integer overflow while decoding deep tile chunks could lead to an out-of-bounds access. Both are reachable simply by opening a crafted file and result in a crash rather than corrupting memory in an attacker-controlled way.

Beyond the formally-numbered CVEs, this release includes a large batch of fixes found by the same audit/fuzzing effort:

• reject truncated or short compressed streams before unpacking (zlib, RLE, DWA, NO_COMPRESSION) instead of reading past the end of the input;
• reject oversized allocation requests instead of overflowing size computations (Array2D, exrmetrics, exrmultipart channel stores, DWAA/B44 scratch buffers);
• add NULL-pointer checks in several OpenEXRCore C-API setters (channel list duplication, preview image, bytes attributes);
• fix a Name::operator= truncation/termination bug;
• close a double-free warning in ImfTiledMisc.

This release also fixes a long-standing correctness bug (not a security issue) in byte-swapping float-vector attributes that caused incorrect results and test failures on big-endian s390x builds.

This release also bumps the vendored OpenJPH version to 0.31.0.

CVEs addressed:

• CVE-2026-68514 PyOpenEXR deep prefixed literal RGB key collision heap buffer overflow
• CVE-2026-68513 PyOpenEXR prefixed literal RGB key collision heap buffer overflow
• CVE-2026-62986 PyOpenEXR deep prefixed RGB stale lane disclosure
• CVE-2026-61703 PyOpenEXR deep mixed RGB heap buffer overflow
• CVE-2026-61555 empty multiView viewFromChannelName file crash
• CVE-2026-59985 ILP32 OpenEXRCore RLE decode heap OOB read DoS
• CVE-2026-59984 ILP32 B44 InputFile decode scratch buffer overflow
• CVE-2026-59983 ILP32 DeepTiledInputFile sample count table decode OOB read
• CVE-2026-59982 ILP32 DWAA InputFile packed AC buffer overflow
• CVE-2026-59981 OpenEXRUtil SampleCountChannel row nonzero dataWindow heap OOB read
• CVE-2026-59189 OpenEXRUtil DeepImageChannel row nonzero dataWindow heap OOB read
• CVE-2026-59187 OpenEXR exrmetrics deep pixelmode heap buffer overflow
• CVE-2026-59186 OpenEXR ILP32 TiledRgbaInputFile large tile Array2D heap OOB write
• CVE-2026-59184 OpenEXRUtil FlatImageChannel row nonzero dataWindow heap OOB write
• CVE-2026-59183 Signed Integer Overflow Leading to Out-of-Bounds Memory Access in Deep Tile Decoding