Threat Intelligence Database

An integer overflow vulnerability exists in AcademySoftwareFoundation's OpenEXR library versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13. The overflow occurs during decoding of crafted deep tiled EXR files, leading to a crash due to an invalid memory read. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

OpenEXR versions prior to 3.2.10, 3.3.12, and 3.4.13 contain an integer overflow vulnerability in the SampleCountChannel component. This flaw causes an infinite loop when the sample-list size is rounded up to the next power of two, due to a 32-bit unsigned integer wraparound. The issue can be triggered via public APIs by setting a pixel's sample count to UINT_MAX. The vulnerability has been fixed in versions 3.2.10, 3.3.12, and 3.4.13.

A NULL pointer dereference vulnerability exists in AcademySoftwareFoundation's OpenEXR versions 3.4.0 through 3.4.12 in the exr_attr_set_bytes() function. This occurs when a positive hint_length is provided with a NULL type_hint pointer, leading to a crash and denial of service. The issue is fixed in version 3.4.13.

OpenEXR versions prior to 3.2.10, 3.3.12, and 3.4.13 contain a heap out-of-bounds write vulnerability in the SampleCountChannel::set function. This occurs because the Y coordinate is incorrectly computed using dataWindow.min.x instead of dataWindow.min.y, leading to potential heap corruption and process crashes when handling deep image data. The issue is reachable via the public DeepImage API and has been fixed in the specified versions.

A vulnerability in OpenEXR versions 3.4.0 through 3.4.12 allows a crafted HTJ2K-compressed EXR file to cause an unconditional process abort when exr_start_read() is called on untrusted input. This is due to an assertion failure triggered by invalid QCD marker bits passed to the OpenJPH library, resulting in a denial of service. The issue is fixed in version 3.4.13.

A reachable assertion vulnerability in AcademySoftwareFoundation's openexr versions 3.4.0 through 3.4.12 allows a crafted HTJ2K-compressed EXR file to cause an unconditional process abort when exr_start_read() is called on untrusted input. This results in a denial of service. The issue arises from an assertion failure in the OpenJPH library triggered by a QCD marker with invalid bits. The vulnerability is fixed in version 3.4.13.

A vulnerability in AcademySoftwareFoundation's OpenEXR versions 3.4.0 through 3.4.13 allows a crafted HTJ2K-compressed EXR file to cause a denial of service via a stack out-of-bounds write. The issue arises when the JPEG 2000 SIZ fields specify tile geometry that places the first tile outside the visible image, leading to invalid tile and codeblock geometry in the OpenJPH AVX2 decoder. This flaw is fixed in version 3.4.14.

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line->i32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, an integer overflow in ht_undo_impl() in src/lib/OpenEXRCore/internal_ht.cpp leads to a heap-buffer overflow when decoding a crafted HTJ2K-compressed EXR file. decode->channels[i].width (int32_t) is multiplied by bytes_per_element in 32-bit signed arithmetic. With large widths (e.g., >= 536870912 for FLOAT data), this overflows, producing a corrupted offset that is later used for pointer arithmetic and can cause a heap out-of-bounds write. The same unchecked multiplication pattern appears in two other HTJ2K paths (bytes-per-line accumulation and pixel-line pointer advancement). As with related CVE-2026-34378 through CVE-2026-34589 fixes in other codecs, validating only after the multiplication is too late because the value may already be overflowed. This issue has been fixed in version 3.4.12.

An integer overflow or wraparound vulnerability exists in the AcademySoftwareFoundation openexr library in the readVariableLengthInteger() function. This function decodes variable-length integers from untrusted EXR input without properly bounding the shift count, leading to undefined behavior when a left shift by 70 bits on a 64-bit value occurs. The issue affects versions 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.