Filtered by vendor Openexr
Subscribe
Total
76 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2017-9114 | 1 Openexr | 1 Openexr | 2026-05-13 | 4.3 MEDIUM | 6.5 MEDIUM |
| In OpenEXR 2.2.0, an invalid read of size 1 in the refill function in ImfFastHuf.cpp could cause the application to crash. | |||||
| CVE-2017-9113 | 1 Openexr | 1 Openexr | 2026-05-13 | 4.3 MEDIUM | 8.8 HIGH |
| In OpenEXR 2.2.0, an invalid write of size 1 in the bufferedReadPixels function in ImfInputFile.cpp could cause the application to crash or execute arbitrary code. | |||||
| CVE-2017-9112 | 1 Openexr | 1 Openexr | 2026-05-13 | 4.3 MEDIUM | 6.5 MEDIUM |
| In OpenEXR 2.2.0, an invalid read of size 1 in the getBits function in ImfHuf.cpp could cause the application to crash. | |||||
| CVE-2017-14988 | 1 Openexr | 1 Openexr | 2026-05-13 | 4.3 MEDIUM | 5.5 MEDIUM |
| ** DISPUTED ** Header::readfrom in IlmImf/ImfHeader.cpp in OpenEXR 2.2.0 allows remote attackers to cause a denial of service (excessive memory allocation) via a crafted file that is accessed with the ImfOpenInputFile function in IlmImf/ImfCRgbaFile.cpp. NOTE: The maintainer and multiple third parties believe that this vulnerability isn't valid. | |||||
| CVE-2017-9111 | 1 Openexr | 1 Openexr | 2026-05-13 | 6.8 MEDIUM | 8.8 HIGH |
| 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. | |||||
| CVE-2017-9116 | 1 Openexr | 1 Openexr | 2026-05-13 | 4.3 MEDIUM | 6.5 MEDIUM |
| In OpenEXR 2.2.0, an invalid read of size 1 in the uncompress function in ImfZip.cpp could cause the application to crash. | |||||
| CVE-2017-9110 | 1 Openexr | 1 Openexr | 2026-05-13 | 4.3 MEDIUM | 6.5 MEDIUM |
| In OpenEXR 2.2.0, an invalid read of size 2 in the hufDecode function in ImfHuf.cpp could cause the application to crash. | |||||
| CVE-2017-12596 | 1 Openexr | 1 Openexr | 2026-05-13 | 6.8 MEDIUM | 7.8 HIGH |
| In OpenEXR 2.2.0, a crafted image causes a heap-based buffer over-read in the hufDecode function in IlmImf/ImfHuf.cpp during exrmaketiled execution; it may result in denial of service or possibly unspecified other impact. | |||||
| CVE-2017-9115 | 1 Openexr | 1 Openexr | 2026-05-13 | 6.8 MEDIUM | 8.8 HIGH |
| In OpenEXR 2.2.0, an invalid write of size 2 in the = operator function in half.h could cause the application to crash or execute arbitrary code. | |||||
| CVE-2026-42217 | 1 Openexr | 1 Openexr | 2026-05-08 | N/A | 9.8 CRITICAL |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From versions 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11, readVariableLengthInteger() decodes a variable-length integer from untrusted EXR input without bounding the shift count. After enough continuation bytes, the code executes a left shift by 70 on a 64-bit value, which is undefined behavior. This issue has been patched in versions 3.2.9, 3.3.11, and 3.4.11. | |||||
| CVE-2026-41142 | 1 Openexr | 1 Openexr | 2026-05-08 | N/A | 8.8 HIGH |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From versions 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11, there is an integer overflow in ImageChannel::resize that leads to heap OOB write via OpenEXRUtil public API. This issue has been patched in versions 3.2.9, 3.3.11, and 3.4.11. | |||||
| CVE-2026-42216 | 1 Openexr | 1 Openexr | 2026-05-08 | N/A | 9.1 CRITICAL |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From versions 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11, IDManifest::init() reconstructs strings from a prefix-compressed representation. If the previous string is longer than 255 bytes, the next string is expected to begin with a 2-byte prefix length. The code reads stringList[i][0] and stringList[i][1] without checking that the current string has at least two bytes. This issue has been patched in versions 3.2.9, 3.3.11, and 3.4.11. | |||||
| CVE-2009-1720 | 1 Openexr | 1 Openexr | 2026-04-23 | 7.5 HIGH | N/A |
| Multiple integer overflows in OpenEXR 1.2.2 and 1.6.1 allow context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via unspecified vectors that trigger heap-based buffer overflows, related to (1) the Imf::PreviewImage::PreviewImage function and (2) compressor constructors. NOTE: some of these details are obtained from third party information. | |||||
| CVE-2009-1721 | 6 Apple, Canonical, Debian and 3 more | 6 Mac Os X, Ubuntu Linux, Debian Linux and 3 more | 2026-04-23 | 6.8 MEDIUM | N/A |
| The decompression implementation in the Imf::hufUncompress function in OpenEXR 1.2.2 and 1.6.1 allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via vectors that trigger a free of an uninitialized pointer. | |||||
| CVE-2009-1722 | 1 Openexr | 1 Openexr | 2026-04-23 | 6.8 MEDIUM | N/A |
| Heap-based buffer overflow in the compression implementation in OpenEXR 1.2.2 allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via unspecified vectors. | |||||
| CVE-2026-40250 | 1 Openexr | 1 Openexr | 2026-04-22 | N/A | 7.1 HIGH |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.4.0 through 3.4.9, 3.3.0 through 3.3.9, and 3.2.0 through 3.2.7, `internal_dwa_compressor.h:1040` performs `chan->width * chan->bytes_per_element` in `int32` arithmetic without a `(size_t)` cast. This is the same overflow pattern fixed in other decoders by CVE-2026-34589/34588/34544, but this line was missed. Versions 3.4.10, 3.3.10, and 3.2.8 contain a fix that addresses `internal_dwa_compressor.h:1040`. | |||||
| CVE-2026-40244 | 1 Openexr | 1 Openexr | 2026-04-22 | N/A | 7.1 HIGH |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.4.0 through 3.4.9, 3.3.0 through 3.3.9, and 3.2.0 through 3.2.7, `internal_dwa_compressor.h:1722` performs `curc->width * curc->height` in `int32` arithmetic without a `(size_t)` cast. This is the same overflow pattern fixed in other locations by the recent CVE-2026-34589 batch, but this line was missed. Versions 3.4.10, 3.3.10, and 3.2.8 contain a fix that addresses `internal_dwa_compressor.h:1722`. | |||||
| CVE-2026-39886 | 1 Openexr | 1 Openexr | 2026-04-22 | N/A | 5.3 MEDIUM |
| OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. Versions 3.4.0 through 3.4.9 have a signed integer overflow vulnerability in OpenEXR's HTJ2K (High-Throughput JPEG 2000) decompression path. The `ht_undo_impl()` function in `src/lib/OpenEXRCore/internal_ht.cpp` accumulates a bytes-per-line value (`bpl`) using a 32-bit signed integer with no overflow guard. A crafted EXR file with 16,385 FLOAT channels at the HTJ2K maximum width of 32,767 causes `bpl` to overflow `INT_MAX`, producing undefined behavior confirmed by UBSan. On an allocator-permissive host where the required ~64 GB allocation succeeds, the wrapped negative `bpl` value would subsequently be used as a per-scanline pointer advance, which would produce a heap out-of-bounds write. On a memory-constrained host, the allocation fails before `ht_undo_impl()` is entered. This is the second distinct integer overflow in `ht_undo_impl()`. CVE-2026-34545 addressed a different overflow in the same function — the `int16_t p` pixel-loop counter at line ~302 that overflows when iterating over channels whose `width` exceeds 32,767. The CVE-2026-34545 fix did not touch the `int bpl` accumulator at line 211, which is the subject of this advisory. The `bpl` accumulator was also not addressed by any of the 8 advisories in the 2026-04-05 v3.4.9 release batch. This finding is structurally identical to CVE-2026-34588 (PIZ `wcount*nx` overflow in `internal_piz.c`) and should be remediated with the same pattern. The CVE-2026-34588 fix did not touch `internal_ht.cpp`. Version 3.4.10 contains a remediation that addresses the vulnerability in `internal_ht.cpp`. | |||||
| CVE-2026-34543 | 1 Openexr | 1 Openexr | 2026-04-07 | N/A | 7.5 HIGH |
| 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-34544 | 1 Openexr | 1 Openexr | 2026-04-07 | N/A | 7.3 HIGH |
| 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. | |||||