https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 06:39:35 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-45696 <p><strong>Affected:</strong> Alpaquita:stream: openexr</p> <p><strong>Affected:</strong> Alpaquita:stream: openexr</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-45696 https://cve.radiocsirt.org/vuln/euvd-2026-337226 EUVD-2026-337226 https://cve.radiocsirt.org/vuln/euvd-2026-337226 https://cve.radiocsirt.org/vuln/fkie_cve-2026-45696 <p>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&#39;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-&gt;i32[] without checking the OpenJPH line buffer&#39;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.</p> <p>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&#39;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-&gt;i32[] without checking the OpenJPH line buffer&#39;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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-45696 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10985-1 <p>libIex-3_4-33-3.4.12-1.1 on GA media</p> <p>libIex-3_4-33-3.4.12-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10985-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45696 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: openexr, Ubuntu:Pro:18.04:LTS: openexr, Ubuntu:Pro:20.04:LTS: openexr, Ubuntu:Pro:22.04:LTS: openexr, Ubuntu:Pro:24.04:LTS: openexr, Ubuntu:25.10: openexr, Ubuntu:Pro:26.04:LTS: openexr</p> <p>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&#39;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-&gt;i32[] without checking the OpenJPH line buffer&#39;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.</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: openexr, Ubuntu:Pro:18.04:LTS: openexr, Ubuntu:Pro:20.04:LTS: openexr, Ubuntu:Pro:22.04:LTS: openexr, Ubuntu:Pro:24.04:LTS: openexr, Ubuntu:25.10: openexr, Ubuntu:Pro:26.04:LTS: openexr</p> <p>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&#39;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-&gt;i32[] without checking the OpenJPH line buffer&#39;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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45696