Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 bug is reachable from the public decoder path and can be reproduced through the shipped exrcheck tool with a crafted scanline DWAA file. The confirmed dynamic symptom is a write-side crash in the lossy DCT execution path. Tested on commit: 7820b7e1b93405ba1d551c43a945018226b75bc5 Root Cause and Data Flow The vulnerable pointer construction lives in src/lib/OpenEXRCore/internaldwadecoder.h: The expression numBlocksX 64 is computed as signed int. Once numBlocksX is large enough, the multiplication wraps, and rowBlock[comp] points backward rather than forward into the temporary decode buffer. Later, LossyDctDecoderexecute() uses those derived pointers for real loads and stores during the block shuffle and reconstruction…
Recommended action: Upgrade to 3.4.9, 3.3.9 or 3.2.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
internalexrundopiz() 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. Tested on commit 7820b7e1b93405ba1d551c43a945018226b75bc5 Technical Details The vulnerable decode path is: 1. internalexrundopiz() sets wavbuf = decode-scratchbuffer1. 2. For each channel, it calls wav2Ddecode (wavbuf + j, ...). 3. It then advances wavbuf with wavbuf += nx ny wcount. The overflow happens in step 3. Once wavbuf is wrapped, the next channel's wavelet decode runs on the wrong address. In the 14-bit wavelet path, wdec144() first reads: - px - p10 - p01 - p11 and then writes back to the same locations: - px = ... - p01 = ... - p10 = ... - p11 = ... As a result, the bug is not just a crash-only invalid read. It is an…
Recommended action: Upgrade to 3.4.9, 3.3.9 or 3.2.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A heap-buffer-overflow (OOB read) occurs in the istreamnonparallelread function in ImfContextInit.cpp when parsing a malformed EXR file through a memory-mapped IStream. A signed integer subtraction produces a negative value that is implicitly converted to sizet, resulting in a massive length being passed to memcpy. Affected Version - OpenEXR main branch (commit at time of testing) - src/lib/OpenEXR/ImfContextInit.cpp, lines 121–136 Root Cause ImfContextInit.cpp:121-126: sz is of type sizet (unsigned), but streamsz - nend yields a negative int64t value. This negative value is implicitly converted to sizet, wrapping around to a value close to 2^64, which is then passed to memcpy causing a heap-buffer-overflow. Suggested fix: sz = streamsz - nend → sz = streamsz - nread Reproduce Build OpenEXR as static libraries with ASAN enabled, then compile the PoC below. PoC Code: PoC Input: https://drive.google.com/file/d/1VhjdK11LA0LHdW1mJJIQEo64mc5tpOUV/view?usp=drivelink ASAN Log Impact…
Recommended action: Upgrade to 3.4.5 or 3.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There is a use-after-free in PyObjectStealAttrString of pyOpenEXRold.cpp. This bug was found with ZeroPath. Details The legacy adapter defines PyObjectStealAttrString that calls PyObjectGetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLongAsLong/PyFloatAsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.). https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXRold.cpp#L109-L115 https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXRold.cpp#L380-L387 https://github.com/AcademySoftwareFoundation/openexr/blob/b3a19903db0672c63055023aa788e592b16ec3c5/src/wrappers/python/PyOpenEXRold.cpp#L1258-L1286 PoC running Impact Completely depends on the context. Typical memory stuff…
Recommended action: Upgrade to 3.4.3, 3.3.6 or 3.2.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). This bug was found with ZeroPath. Details Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit), around here. - In channel(): - Width and height are derived from the header dataWindow using int. - typeSize is a sizet. The buffer size is computed as typeSize width height with no bounds checks. - The result is passed to PyStringFromStringAndSize(NULL, size) which maps to PyBytesFromStringAndSize. That function expects Pyssizet. If the product overflows or exceeds PYSSIZETMAX, allocation fails or the value wraps. -…
Recommended action: Upgrade to 3.4.3, 3.3.6 or 3.2.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While fuzzing openexrexrcheckfuzzer, Valgrind reports a conditional branch depending on uninitialized data inside genericunpack. This indicates a use of uninitialized memory (CWE-457). The issue is reproducible with the current OSS-Fuzz harness and a single-file PoC. Details Environment: - Tooling: valgrind --tool=memcheck --track-origins=yes - Target: openexrexrcheckfuzzer - OS: Ubuntu 20.04.6 LTS focal x8664 - openexr version and Git-commit hash: openexr 3.4.2 | commit fd657e8a41e157e5841c7cc2e2a5efe094b069a1 (grafted, HEAD - main, origin/main, origin/HEAD) Function: genericunpack Possible root cause (based on observed symptoms): The unpacker is branching on bytes in a scratch buffer that were never written because the decode step didn’t fully populate it. - The first use flagged is in genericunpack(). That function reads from the decompressed/expanded pixel buffer to scatter data into the framebuffer. A “conditional jump depends on uninitialised value(s)” means it’s…
Recommended action: Upgrade to 3.4.3 or 3.3.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PXR24 decompression function undopxr24impl in OpenEXR (internalpxr24.c) ignores the actual decompressed size (outSize) returned by exruncompressbuffer() and instead reads from the scratch buffer based solely on the expected size (uncompressedsize) derived from the header metadata. Additionally, exruncompressbuffer() (compression.c:202) treats LIBDEFLATESHORTOUTPUT (where the compressed stream decompresses to fewer bytes than expected) as a successful result rather than an error. When these two issues are combined, an attacker can craft a PXR24 EXR file containing a valid but truncated zlib stream. As a result, the decoder reads uninitialized heap memory and incorporates it into the output pixel data. Details This issue occurs due to the combination of two flaws. 1. compression.c:202–205 — LIBDEFLATESHORTOUTPUT treated as success libdeflatezlibdecompressex() returns LIBDEFLATESHORTOUTPUT when the compressed stream is successfully decompressed but the resulting output size…
Recommended action: Upgrade to 3.4.8; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The B44/B44A decoder in OpenEXR reconstructs row pointers into a scratch buffer using int. When the channel width (nx) is large enough, the product y nx overflows int, causing the row pointer to wrap before the start of the scratch buffer. Subsequent memcpy() calls then write decoded pixel blocks to an invalid address, producing an active out-of-bounds write. Root cause Variable declarations (internalb44.c:535) nx and ny are declared as plain int. They are assigned from curc-width and curc-height which are int32t. Scratch buffer allocation (internalb44:543) The allocation path correctly promotes to uint64t before multiplying. The scratch buffer is always large enough to hold the full channel. Row pointer reconstruction (internalb44:560) y and nx are both int. The product y nx is computed in int. If this product exceeds INTMAX (2,147,483,647), the result is signed integer overflow Out of Band write (internalb44:592) These four writes copy decoded B44 pixel blocks into…
Recommended action: Upgrade to 3.4.8; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Function: CompositeDeepScanLine::readPixels, reachable from high-level multipart deep read flows (MultiPartInputFile + DeepScanLineInputPart + CompositeDeepScanLine). Vulnerable lines (src/lib/OpenEXR/ImfCompositeDeepScanLine.cpp): - totalsizes[ptr] += counts[j][ptr]; (line ~511) - overallsamplecount += totalsizes[ptr]; (line ~514) - samples[channel].resize (overallsamplecount); (line ~535) Impact: 32-bit sample-count accumulation wrap leads to undersized allocation, then decode writes with true sample volume, causing heap OOB write in genericunpackdeeppointers (src/lib/OpenEXRCore/unpack.c:1374) (DoS/Crash, memory corruption/RCE). Attack scenario: - Attacker provides multipart deep EXR with many parts and very large sample counts per pixel. - Uses compression (RLE/ZIPS) to keep file size relatively small vs decode pressure. - The overflow happens in composite sample accounting (unsigned int), while pointer progression for decode uses larger counters and reaches…
Recommended action: Upgrade to 3.4.6, 3.3.8 or 3.2.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of dataWindow size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations. Details A concrete example of this issue is present in the function readScanline() in ImfCheckFile.cpp at line 235, that performs a for-loop using the dataWindow min.y and max.y coordinates that can be arbitrarily large. Another example occurs in the EnvmapImage::resize function that in turn calls Array2D<T::resizeEraseUnsafe passing the dataWindow X and Y coordinates and perform a huge allocation. On some system, the allocator will simply return std::badalloc and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate…
Recommended action: Upgrade to 3.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When reading a deep scanline image with a large sample count in reduceMemory mode, it is possible to crash a target application with a NULL pointer dereference in a write operation. Details In the ScanLineProcess::runfill function, implemented in src/lib/OpenEXR/ImfDeepScanLineInputFile.cpp, the following code is used to write the fillValue in the sample buffer: However, when reduceMemory mode is enabled in the readDeepScanLine function in src/lib/OpenEXRUtil/ImfCheckFile.cpp, with large sample counts, the sample data will not be read, as shown below: Therefore, in those cases, the sample buffer would not be allocated, resulting in a potential write operation on a NULL pointer. PoC NOTE: please download the runfillcrash.exr file from the following link: https://github.com/ShielderSec/poc/tree/main/CVE-2025-48073 1. Compile the exrcheck binary in a macOS or GNU/Linux machine with ASAN. 2. Open the runfillcrash.exr file with the following command: 3. Notice that exrcheck…
Recommended action: Upgrade to 3.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. Details In the LossyDctDecoderexecute function (from src/lib/OpenEXRCore/internaldwadecoder.h, when SSE2 is enabled), the following code is used to copy data from the chunks: The issue arises because the src pointer, which is a si128 pointer, is incremented by 88, as if it were a uint16t pointer (64 uint16t == 128 bytes). In non-block aligned chunks (width/height not a multiple of 8), this can cause src to point past the boundaries of the chunk. PoC In order to reproduce the PoC with fidelity and avoid undefined behaviors, it is necessary to enable ASAN (and SSE2). Otherwise the out-of-bound read will not be detected until its side-effect causes a crash. NOTE: please download the dwadecodercrash.exr file from the following link:…
Recommended action: Upgrade to 3.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header. Details When parsing STORAGEDEEPSCANLINE chunks from an EXR file, the following code (from src/lib/OpenEXRCore/chunk.c) is used to extract the chunk information: By storing this information, the code that will later decompress and reconstruct the chunk bytes, will know how much space the uncompressed data will occupy. This size is carried along in the chain of decoding/decompression until the undozipimpl function in src/lib/OpenEXRCore/internalzip.c: The uncompressedsize comes from the unpackedsize extracted earlier, and the uncompresseddata is a buffer allocated by making space for the size "advertised" in the chunk information. However, scratchdata and actualoutbytes will contain, after decompression, the uncompressed data and its size, respectively. The vulnerability lies in the fact that…
Recommended action: Upgrade to 3.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In OpenEXR 2.2.0, an invalid write of size 8 in the storeSSE function in ImfOptimizedPixelReading.h could cause the application to crash or execute arbitrary code.
Recommended action: Upgrade to 2.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In OpenEXR 2.2.0, an invalid read of size 1 in the getBits function in ImfHuf.cpp could cause the application to crash.
Recommended action: Upgrade to 2.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.