<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 04:11:13 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-12714</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-12714</link>
      <description>bdu:2025-12714</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-12714</guid>
    </item>
    <item>
      <title>cnvd-2025-24791</title>
      <link>https://cve.radiocsirt.org/vuln/cnvd-2025-24791</link>
      <description>cnvd-2025-24791</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cnvd-2025-24791</guid>
    </item>
    <item>
      <title>EUVD-2026-272051</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-272051</link>
      <description>EUVD-2026-272051</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-272051</guid>
    </item>
    <item>
      <title>fkie_cve-2025-59733</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-59733</link>
      <description>&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;#39;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;. The channel parsing code can be found in decode_header. The buffer td-&amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.&lt;/p&gt;
&lt;p&gt;The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;, and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.&lt;/p&gt;
&lt;p&gt;If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.&lt;/p&gt;
&lt;p&gt;We recommend upgrading to version 8.0 or beyond.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;#39;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;. The channel parsing code can be found in decode_header. The buffer td-&amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.&lt;/p&gt;
&lt;p&gt;The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;, and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.&lt;/p&gt;
&lt;p&gt;If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.&lt;/p&gt;
&lt;p&gt;We recommend upgrading to version 8.0 or beyond.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-59733</guid>
    </item>
    <item>
      <title>GHSA-hpfq-c235-5854</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hpfq-c235-5854</link>
      <description>&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;#39;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;. The channel parsing code can be found in decode_header. The buffer td-&amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.&lt;/p&gt;
&lt;p&gt;The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;, and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.&lt;/p&gt;
&lt;p&gt;If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.&lt;/p&gt;
&lt;p&gt;We recommend upgrading to version 8.0 or beyond.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;#39;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;. The channel parsing code can be found in decode_header. The buffer td-&amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.&lt;/p&gt;
&lt;p&gt;The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;, and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.&lt;/p&gt;
&lt;p&gt;If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.&lt;/p&gt;
&lt;p&gt;We recommend upgrading to version 8.0 or beyond.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hpfq-c235-5854</guid>
    </item>
    <item>
      <title>OESA-2026-3284 — ffmpeg security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3284</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: ffmpeg&lt;/p&gt;
&lt;p&gt;FFmpeg is a complete and free Internet live audio and video broadcasting solution for Linux/Unix. It also includes a digital VCR. It can encode in real time in many formats including MPEG1 audio and video, MPEG4, h263, ac3, asf, avi, real, mjpeg, and flash.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;amp;apos;s an implicit assumption that the height and width are divisible by 8.&lt;/p&gt;
&lt;p&gt;If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.&lt;/p&gt;
&lt;p&gt;The buffer td-&amp;amp;gt;uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the &amp;amp;quot;rounded-up&amp;amp;quot; multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.&lt;/p&gt;
&lt;p&gt;We recommend upgrading to version 8.0 or beyond.(CVE-2025-59732)&lt;/p&gt;
&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;amp;apos;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;amp;quot;B&amp;amp;quot;, &amp;amp;quot;G&amp;amp;quot;, &amp;amp;quot;R&amp;amp;quot; and &amp;amp;quot;A&amp;amp;quot;. The channel parsing code can be found in decode_header. The buffer td-&amp;amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.&lt;/p&gt;
&lt;p&gt;The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;amp;quot;B&amp;amp;quot;, &amp;amp;quot;G&amp;amp;q…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: ffmpeg&lt;/p&gt;
&lt;p&gt;FFmpeg is a complete and free Internet live audio and video broadcasting solution for Linux/Unix. It also includes a digital VCR. It can encode in real time in many formats including MPEG1 audio and video, MPEG4, h263, ac3, asf, avi, real, mjpeg, and flash.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;amp;apos;s an implicit assumption that the height and width are divisible by 8.&lt;/p&gt;
&lt;p&gt;If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.&lt;/p&gt;
&lt;p&gt;The buffer td-&amp;amp;gt;uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the &amp;amp;quot;rounded-up&amp;amp;quot; multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.&lt;/p&gt;
&lt;p&gt;We recommend upgrading to version 8.0 or beyond.(CVE-2025-59732)&lt;/p&gt;
&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;amp;apos;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;amp;quot;B&amp;amp;quot;, &amp;amp;quot;G&amp;amp;quot;, &amp;amp;quot;R&amp;amp;quot; and &amp;amp;quot;A&amp;amp;quot;. The channel parsing code can be found in decode_header. The buffer td-&amp;amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.&lt;/p&gt;
&lt;p&gt;The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;amp;quot;B&amp;amp;quot;, &amp;amp;quot;G&amp;amp;q…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3284</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-59733</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-59733</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: libav, Ubuntu:Pro:18.04:LTS: ffmpeg, Ubuntu:Pro:20.04:LTS: ffmpeg, Ubuntu:Pro:22.04:LTS: ffmpeg, Ubuntu:Pro:24.04:LTS: ffmpeg, Ubuntu:25.10: ffmpeg&lt;/p&gt;
&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;#39;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;. The channel parsing code can be found in decode_header. The buffer td-&amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset. The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;, and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels. If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer. We recommend upgrading to version 8.0 or beyond.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: libav, Ubuntu:Pro:18.04:LTS: ffmpeg, Ubuntu:Pro:20.04:LTS: ffmpeg, Ubuntu:Pro:22.04:LTS: ffmpeg, Ubuntu:Pro:24.04:LTS: ffmpeg, Ubuntu:25.10: ffmpeg&lt;/p&gt;
&lt;p&gt;When decoding an OpenEXR file that uses DWAA or DWAB compression, there&amp;#39;s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;. The channel parsing code can be found in decode_header. The buffer td-&amp;gt;uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset. The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are &amp;#34;B&amp;#34;, &amp;#34;G&amp;#34;, &amp;#34;R&amp;#34; and &amp;#34;A&amp;#34;, and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels. If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer. We recommend upgrading to version 8.0 or beyond.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-59733</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2130 — ffmpeg: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2130</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in ffmpeg ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in ffmpeg ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2130</guid>
    </item>
  </channel>
</rss>
