https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:34:06 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-65979 <p><strong>Affected:</strong> Alpaquita:stream: openexr</p> <p><strong>Affected:</strong> Alpaquita:stream: openexr</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-65979 https://cve.radiocsirt.org/vuln/euvd-2026-358941 EUVD-2026-358941 https://cve.radiocsirt.org/vuln/euvd-2026-358941 https://cve.radiocsirt.org/vuln/fkie_cve-2026-65979 <p>OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk&#39;s compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.</p> <p>OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk&#39;s compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-65979 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11612-1 <p>libIex-3_4-33-3.4.14-1.1 on GA media</p> <p>libIex-3_4-33-3.4.14-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11612-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-65979 <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: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. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk&#39;s compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.</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: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. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk&#39;s compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-65979