CVE-2026-61555 is an out-of-bounds read vulnerability in the AcademySoftwareFoundation's OpenEXR library. It affects versions before 3.2.11, versions from 3.3.0 up to but not including 3.3.13, and versions from 3.4.0 up to but not including 3.4.14. The vulnerability occurs when processing a crafted EXR file with an empty multiView header attribute, leading to an out-of-bounds access in Imf::viewFromChannelName(). This can cause the application to crash. The issue has been fixed in versions 3.2.11, 3.3.13, and 3.4.14. The CVSS score is 5.5, indicating a medium severity impact primarily affecting availability.
OpenEXR, a widely used image format implementation by the AcademySoftwareFoundation, has a heap out-of-bounds read vulnerability on ILP32 builds in versions 3.2.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13. The flaw occurs when a specially crafted RLE-compressed EXR file causes a 64-bit unpacked size truncation before allocation, leading to out-of-bounds reads during decoding. This can result in a denial of service. The issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
CVE-2026-59984 is an out-of-bounds write vulnerability in the AcademySoftwareFoundation openexr library affecting ILP32 builds. The flaw occurs in versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 when processing crafted B44-compressed scanline EXR images. The vulnerability allows an attacker to cause denial of service or memory corruption by triggering a logical scratch size truncation before allocation, leading to unsafe writes. Fixed versions are 3.2.11, 3.3.13, and 3.4.14. The CVSS score is 5.5 (medium severity).
An out-of-bounds read vulnerability (CWE-125) exists in AcademySoftwareFoundation's OpenEXR library on ILP32 builds. The flaw occurs in versions before 3.2.11, from 3.3.0 up to 3.3.12, and from 3.4.0 up to 3.4.13 when processing crafted uncompressed deep-tile EXR files. This causes a sample-count table size calculation to wrap, leading to denial of service. The issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
CVE-2026-59982 is an integer overflow or wraparound vulnerability in the AcademySoftwareFoundation's OpenEXR library. Affected versions include >=3.1.0 <3.2.11, >=3.3.0 <3.3.13, and >=3.4.0 <3.4.14. The flaw allows the TypedDeepImageChannel::row() function to return an out-of-bounds pointer when processing a crafted deep EXR file with a nonzero dataWindow origin. This can lead to a crash or limited information disclosure. The issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14. The CVSS score is 7.1, indicating a high severity vulnerability.
A heap out-of-bounds read vulnerability exists in AcademySoftwareFoundation's OpenEXR library versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.12. The issue occurs in the TypedDeepImageChannel<T>::row() API when handling deep images with a non-zero dataWindow origin, causing row(0) to return a pointer outside the allocated sample list. This can lead to a crash and potential information disclosure under controlled heap conditions. The flaw is due to conflicting coordinate models used internally. Versions 3.3.13 and 3.4.13 contain fixes for this vulnerability.
OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 contain a heap-based buffer overflow vulnerability triggered when exrmetrics processes crafted deep scanline EXR files with specific pixel conversion options. This vulnerability is fixed in versions 3.3.13 and 3.4.14.
A heap-based buffer overflow vulnerability exists in AcademySoftwareFoundation's openexr library in certain versions when processing crafted tiled EXR files on 32-bit/ILP32 builds. The issue arises due to an integer overflow in buffer size calculation, leading to out-of-bounds writes during tile decoding. This vulnerability is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
A use-after-free vulnerability exists in AcademySoftwareFoundation's openexr library in versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13. This flaw allows a crafted EXR image with a nonzero dataWindow.min to cause TypedFlatImageChannel::row() to return an invalid heap pointer, leading to out-of-bounds or use-after-free writes when applications write rows via FlatHalfChannel::row(). The issue affects tools and services processing untrusted EXR files. 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 sample count to UINT_MAX. This vulnerability has been fixed in versions 3.2.10, 3.3.12, and 3.4.13.
OpenEXR versions 3.4.0 through 3.4.12 contain a vulnerability in the exr_attr_set_bytes() function where improper input validation of a nested pointer leads to a NULL pointer dereference. This flaw can cause a deterministic crash resulting in 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. The flaw arises from incorrect computation of the Y coordinate using dataWindow.min.x instead of dataWindow.min.y, which can cause writes before the allocated buffer. This vulnerability can lead to heap corruption and process crashes when using the DeepImage API. The issue has been fixed in versions 3.2.10, 3.3.12, and 3.4.13.
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 exists in AcademySoftwareFoundation's OpenEXR versions 3.4.0 through 3.4.12. A crafted HTJ2K-compressed EXR file with a specific QCD marker causes an unconditional process abort when exr_start_read() is called on untrusted input, leading to denial of service. The issue arises because OpenEXR passes invalid quantization delta parameters to the OpenJPH library, which uses an assertion that triggers abort(). This vulnerability is fixed in version 3.4.13.
OpenEXR versions 3.4.0 through 3.4.13 contain an out-of-bounds write vulnerability in the HTJ2K-compressed EXR decoding path. This occurs when a crafted EXR file has JPEG 2000 SIZ fields that place the first tile outside the visible image, leading to invalid tile and codeblock geometry in the OpenJPH AVX2 decoder. The flaw can cause a denial of service by crashing the application. The issue is fixed in version 3.4.14.
OpenColorIO is a color management framework for visual effects and animation. Prior to version 2.5.2, `FileFormatSpi3D.cpp:163` uses `sscanf` with `%s` into 64-byte stack buffers when parsing LUT data lines. Input comes from `lineBuffer[4096]`, so a crafted .spi3d file can overflow by ~4000 bytes on non-Windows. Version 2.5.2 fixes the issue.
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.
OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, sgiinput.cpp:265,274 use OIIO_DASSERT for bounds checking in the RLE decode loop. In release builds, OIIO_DASSERT compiles to ((void)sizeof(x)) (dassert.h:210), making all bounds checks no-ops. A crafted .sgi file with RLE count exceeding scanline width causes heap buffer overflow and crash. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.
CVE-2026-43904 is a high-severity out-of-bounds write vulnerability in AcademySoftwareFoundation's OpenImageIO prior to versions 3.0.18.0 and 3.1.13.0. The issue occurs in the RLE decoding paths of softimageinput.cpp, where run lengths are not properly clamped to the remaining scanline width, leading to a heap overflow of up to 65535 bytes when processing a crafted . pic image file.