v3.4.15

v3.4.15 fixes two memory issues when parsing IDManifests. Corrupt
or maliciously formed OpenEXR images could trigger excessive memory
allocation, but only in code which decodes the idmanifest attribute.
Other code is unaffected, even when handling files with idmanifest attributes

CVEs have been requested for these issues.

This release also fixes a missing export for Windows builds, and reduces
compiler warnings when compiling example code.

v3.3.14

v3.3.14 fixes two memory issues when parsing IDManifests. Corrupt
or maliciously formed OpenEXR images could trigger excessive memory
allocation, but only in code which decodes the idmanifest attribute.
Other code is unaffected, even when handling files with idmanifest attributes

CVEs have been requested for these issues.

v3.2.12

v3.2.12 fixes two memory issues when parsing IDManifests. Corrupt
or maliciously formed OpenEXR images could trigger excessive memory
allocation, but only in code which decodes the idmanifest attribute.
Other code is unaffected, even when handling files with idmanifest attributes

CVEs have been requested for these issues.

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

v3.3.13

v3.3.13 is a security-focused patch release for the v3.3 release stream. 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.

A handful of the merged pull requests below are incidental hardening rather than fixes for a specific numbered CVE — for example, avoiding an unnecessary allocation in idmanifest parsing, a Name::operator= null-termination fix, and the unrelated (non-security) multi-part loading fix carried over from PR #2148 — but the bulk of this release is driven by the CVEs above.

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

v3.2.11

v3.2.11 is a security-focused patch release for the v3.2 release stream. It fixes 10 CVEs plus a 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:

• 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 with non-default data windows (CVE-2026-59981, CVE-2026-59189, CVE-2026-59186, CVE-2026-59184). FlatImageChannel/DeepImageChannel/SampleCountChannel row addressing assumed a data window originating at (0, 0). Crafted files with a nonzero data window origin 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.

A couple of the merged pull requests below are incidental hardening rather than fixes for a specific numbered CVE — avoiding an unnecessary allocation in idmanifest parsing and a Name::operator= null-termination fix — but the bulk of this release is driven by the CVEs above.

CVEs addressed:

• 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-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

v3.3.12

This release addresses the following security vulnerabilities:

• CVE-2026-55373 OpenEXRUtil SampleCountChannel endEdit() can loop forever on UINT_MAX sample counts
• CVE-2026-55059 OpenEXRUtil SampleCountChannel row setter heap out-of-bounds write
• CVE-2026-54920 Integer Overflow and Use of Uninitialized Pointer leading to Invalid Delete in OpenEXRUtil Image Resize

v3.2.10

Patch release for 3.2 addressing security issues

This release addresses the following security vulnerabilities:

• CVE-2026-55373 OpenEXRUtil SampleCountChannel endEdit() can loop forever on UINT_MAX sample counts
• CVE-2026-55059 OpenEXRUtil SampleCountChannel row setter heap out-of-bounds write
• CVE-2026-54920 Integer Overflow and Use of Uninitialized Pointer leading to Invalid Delete in OpenEXRUtil Image Resize

v3.4.13

Patch release that addresses several bugs and security
vulnerabilities.

• 🐛 Fix a regression introduced in v3.4.11 in decoding of DWAA compression
• 🐛 Fix to handling deep images and very large images with the OpenEXRUtil library
• 🐛 Fix initiliazation issue in B44A decoding
• 🐛 Validate HTJ2K chunk header length before decode
• 🛠️ Fix when building statically and using the vendored OpenJPH library

For the python module:

• 🐍 ✨ Support NumPy scalar values Box2i and V2f tuple bindings

This release addresses the following security vulnerabilities:

• CVE-2026-55373 OpenEXRUtil SampleCountChannel endEdit() can loop forever on UINT_MAX sample counts
• CVE-2026-55371 OpenEXRCore exr_attr_set_bytes() accepts NULL type_hint with positive hint_length
• CVE-2026-55059 OpenEXRUtil SampleCountChannel row setter heap out-of-bounds write
• CVE-2026-54920 Integer Overflow and Use of Uninitialized Pointer leading to Invalid Delete in OpenEXRUtil Image Resize
• CVE-2026-53532 Unhandled assert abort in HTJ2K decoder via crafted QCD marker (DoS)

v3.4.12

Patch release that addresses several bugs and security vulnerabilities.

• 🐛 Fix several minor memory leaks recovering from reading invalid files.
• 🐛 The compressor API incorrectly identified HTJ2K and HTJ2K256 as lossy; they are lossles.
• 🐛 Fix CMake AVX feature detection that caused DWA SIMD code to fail on certain architectures.
• ⚠️ The WidenFilename utility function is marked as deprecated, to be removed in a future release.
• ✨ exrmetrics now print the on-disk size of the data portion of each part. Useful for determining compression impact on part data

For the python module:

• 🐍 🐛 Reject files where the dataWindows does not match the pixel array dimensions.
• 🐍 ✨ Support NumPy float vector attributes
• 🐍 ✨ Reading now skips over invalid parts, returns the valid parts only.
• 🐍 📖 Doc strings have proper indentation

This release addresses the following security vulnerabilities:

• CVE-2026-45696 OpenEXR ht_undo_impl heap-buffer-overflow READ via codestream/channel width mismatch in HTJ2K decode
• CVE-2026-44663 Integer overflow in HTJ2K decoder ( ht_undo_impl ) leading to heap-buffer-overflow
• OSS-Fuzz 512895184 Null-dereference WRITE in Imf_4_0::TileProcess::run_decode
• OSS-fuzz 512314697 Direct-leak in internal_exr_add_part
• OSS-fuzz 508362159 Heap-buffer-overflow in DwaCompressor_uncompress
• OSS-fuzz 507413960 Heap-buffer-overflow in generic_unpack