Academysoftwarefoundation vulnerabilities, page 4
76 vulnerabilities
Known vulnerabilities in Academysoftwarefoundation products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 4 products.
CVE-2026-43904academysoftwarefoundationopenimageio+3
EPSS score0.18%
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, softimageinput.cpp:469 (mixed RLE) and :345 (pure RLE) do not clamp the run length to remaining scanline width before writing pixels. The raw packet path (line 403) correctly clamps with std::min, but RLE paths skip this check. A crafted .pic file causes heap overflow up to 65535 bytes. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.CVE-2026-7582academysoftwarefoundationopenimageio+4EPSS score0.16%
A vulnerability was detected in AcademySoftwareFoundation OpenImageIO up to 3.2.0.1-dev. This vulnerability affects unknown code of the file src/dds.imageio/ddsinput.cpp of the component DDS Image Handler. The manipulation results in out-of-bounds write. The attack needs to be approached locally. The exploit is now public and may be used. The patch is identified as 94ec2deec3e3bf2f2e2ff84d008e27425d626fe2. Applying a patch is advised to resolve this issue.CVE-2026-53532academysoftwarefoundationopenexr+2EPSS score0.45%
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.12, a crafted HTJ2K-compressed EXR file causes an unconditional process abort in any application that calls exr_start_read() on untrusted input, resulting in denial of service. The crash is triggered by a QCD marker whose lower five bits are zero, which OpenEXR passes into the vendored OpenJPH library while constructing the codestream and evaluating its quantization delta parameters. OpenJPH uses an assertion rather than a recoverable error to validate those bits, so any invalid value calls abort() directly and cannot be intercepted by surrounding error handling, a problem compounded by OpenEXR wrapping only its internal HT header parser in error handling while leaving the later codestream read and construction calls unprotected. This issue has been resolved in version 3.4.13.CVE-2026-27622academysoftwarefoundationopenexr+14EPSS score0.23%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In CompositeDeepScanLine::readPixels, per-pixel totals are accumulated in vector<unsigned int> total_sizes for attacker-controlled large counts across many parts, total_sizes[ptr] wraps modulo 2^32. overall_sample_count is then derived from wrapped totals and used in samples[channel].resize(overall_sample_count). Decode pointer setup/consumption proceeds with true sample counts, and write operations in core unpack (generic_unpack_deep_pointers) overrun the undersized composite sample buffer. This vulnerability is fixed in v3.2.6, v3.3.8, and v3.4.6.CVE-2026-67549academysoftwarefoundationopenimageio+2EPSS score0.29%
OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.1.16.0, A crafted 1-bit contiguous cmyk tiff is exposed through a native uint1 imagespec, so callers allocate a bit-packed buffer. tiffinput::read_native_scanline_locked() nevertheless invokes tiffinput::bit_convert() with 8-bit output and writes one expanded byte per value into that smaller buffer, resulting in a heap out-of-bounds write and memory corruption. The affected implementation is identified by src/tiff.imageio/tiffinput.cpp, TIFFInput::bit_convert(), TIFFInput::read_native_scanline_locked(), PHOTOMETRIC_SEPARATED, 1-bit CMYK, and native uint1 ImageSpec, which define the relevant source path, functions, state, and trigger. This issue is fixed in 3.1.16.0.CVE-2026-44663academysoftwarefoundationopenexr+3EPSS score0.21%
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.CVE-2026-45696academysoftwarefoundationopenexr+3EPSS score0.42%
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.CVE-2026-34378academysoftwarefoundationopenexr+3EPSS score0.39%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.4.0 to before 3.4.9, a missing bounds check on the dataWindow attribute in EXR file headers allows an attacker to trigger a signed integer overflow in generic_unpack(). By setting dataWindow.min.x to a large negative value, OpenEXRCore computes an enormous image width, which is later used in a signed integer multiplication that overflows, causing the process to terminate with SIGILL via UBSan. This vulnerability is fixed in 3.4.9.CVE-2026-34589academysoftwarefoundationopenexr+4EPSS score0.48%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, the DWA lossy decoder constructs temporary per-component block pointers using signed 32-bit arithmetic. For a large enough width, the calculation overflows and later decoder stores operate on a wrapped pointer outside the allocated rowBlock backing store. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.CVE-2026-34588academysoftwarefoundationopenexr+10EPSS score0.57%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.1.0 to before 3.2.7, 3.3.9, and 3.4.9, internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic. Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.CVE-2026-34543academysoftwarefoundationopenexr+20EPSS score0.52%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From version 3.4.0 to before version 3.4.8, sensitive information from heap memory may be leaked through the decoded pixel data (information disclosure). This occurs under default settings; simply reading a malicious EXR file is sufficient to trigger the issue, without any user interaction. This issue has been patched in version 3.4.8.CVE-2026-34544academysoftwarefoundationopenexr+20EPSS score0.21%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From version 3.4.0 to before version 3.4.8, a crafted B44 or B44A EXR file can cause an out-of-bounds write in any application that decodes it via exr_decoding_run(). Consequences range from immediate crash (most likely) to corruption of adjacent heap allocations (layout-dependent). This issue has been patched in version 3.4.8.CVE-2026-34545academysoftwarefoundationopenexr+19EPSS score0.74%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From version 3.4.0 to before version 3.4.7, an attacker providing a crafted .exr file with HTJ2K compression and a channel width of 32768 can write controlled data beyond the output heap buffer in any application that decodes EXR images. The write primitive is 2 bytes per overflow iteration or 4 bytes (by another path), repeating for each additional pixel past the overflow point. In this context, a heap write overflow can lead to remote code execution on systems. This issue has been patched in version 3.4.7.CVE-2026-34380academysoftwarefoundationopenexr+3EPSS score0.38%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a signed integer overflow exists in undo_pxr24_impl() in src/lib/OpenEXRCore/internal_pxr24.c at line 377. The expression (uint64_t)(w * 3) computes w * 3 as a signed 32-bit integer before casting to uint64_t. When w is large, this multiplication constitutes undefined behavior under the C standard. On tested builds (clang/gcc without sanitizers), two's-complement wraparound commonly occurs, and for specific values of w the wrapped result is a small positive integer, which may allow the subsequent bounds check to pass incorrectly. If the check is bypassed, the decoding loop proceeds to write pixel data through dout, potentially extending far beyond the allocated output buffer. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.CVE-2026-34379academysoftwarefoundationopenexr+3EPSS score0.46%
OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.CVE-2026-50291academysoftwarefoundationopenimageio+3EPSS score0.20%
OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to versions 3.0.16.0 and 3.1.11.0, processing a crafted BMP file through oiiotool or an application linked to OpenImageIO can reach BMP palette handling in src/bmp.imageio/bmpinput.cpp with an empty color table. BmpInput::read_native_scanline then performs an invalid palette read while decoding an RLE-compressed scanline, causing a process crash and denial of service. This issue is fixed in versions 3.0.16.0 and 3.1.11.0.