<?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>Sat, 03 Oct 2026 07:13:47 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-05909</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-05909</link>
      <description>bdu:2025-05909</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-05909</guid>
    </item>
    <item>
      <title>BREW-mailcatcher-CVE-2025-43857 — net-imap rubygem vulnerable to possible DoS by memory exhaustion</title>
      <link>https://cve.radiocsirt.org/vuln/brew-mailcatcher-cve-2025-43857</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: mailcatcher&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;There is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses.  At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread.  The response reader immediately allocates memory for the number of bytes indicated by the server response.&lt;/p&gt;
&lt;p&gt;This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved.  It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The IMAP protocol allows &amp;#34;literal&amp;#34; strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\r\n`).  When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size.  When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues.  The server does not need to send any more data.  There is no limit on the size of literals that will be accepted.&lt;/p&gt;
&lt;p&gt;### Fix
#### Upgrade
Users should upgrade to `net-imap` 0.5.7 or later.  A configurable `max_response_size` limit has been added to `Net::IMAP`&amp;#39;s response reader.  The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.&lt;/p&gt;
&lt;p&gt;To set a global value for `max_response_size`, users must upgrade to `net-imap` ~&amp;gt; 0.4.20, or &amp;gt; 0.5.7.&lt;/p&gt;
&lt;p&gt;#### Configurat…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: mailcatcher&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;There is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses.  At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread.  The response reader immediately allocates memory for the number of bytes indicated by the server response.&lt;/p&gt;
&lt;p&gt;This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved.  It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The IMAP protocol allows &amp;#34;literal&amp;#34; strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\r\n`).  When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size.  When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues.  The server does not need to send any more data.  There is no limit on the size of literals that will be accepted.&lt;/p&gt;
&lt;p&gt;### Fix
#### Upgrade
Users should upgrade to `net-imap` 0.5.7 or later.  A configurable `max_response_size` limit has been added to `Net::IMAP`&amp;#39;s response reader.  The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.&lt;/p&gt;
&lt;p&gt;To set a global value for `max_response_size`, users must upgrade to `net-imap` ~&amp;gt; 0.4.20, or &amp;gt; 0.5.7.&lt;/p&gt;
&lt;p&gt;#### Configurat…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-mailcatcher-cve-2025-43857</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0756 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0756</link>
      <description>certfr-2025-avi-0756</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0756</guid>
    </item>
    <item>
      <title>EUVD-2026-235445</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-235445</link>
      <description>EUVD-2026-235445</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-235445</guid>
    </item>
    <item>
      <title>fkie_cve-2025-43857</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-43857</link>
      <description>&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-43857</guid>
    </item>
    <item>
      <title>GHSA-j3g3-5qv5-52mj — net-imap rubygem vulnerable to possible DoS by memory exhaustion</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-j3g3-5qv5-52mj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: net-imap&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;There is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses.  At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread.  The response reader immediately allocates memory for the number of bytes indicated by the server response.&lt;/p&gt;
&lt;p&gt;This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved.  It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The IMAP protocol allows &amp;#34;literal&amp;#34; strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\r\n`).  When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size.  When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues.  The server does not need to send any more data.  There is no limit on the size of literals that will be accepted.&lt;/p&gt;
&lt;p&gt;### Fix
#### Upgrade
Users should upgrade to `net-imap` 0.5.7 or later.  A configurable `max_response_size` limit has been added to `Net::IMAP`&amp;#39;s response reader.  The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.&lt;/p&gt;
&lt;p&gt;To set a global value for `max_response_size`, users must upgrade to `net-imap` ~&amp;gt; 0.4.20, or &amp;gt; 0.5.7.&lt;/p&gt;
&lt;p&gt;#### Configurat…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: net-imap&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;There is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses.  At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread.  The response reader immediately allocates memory for the number of bytes indicated by the server response.&lt;/p&gt;
&lt;p&gt;This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved.  It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The IMAP protocol allows &amp;#34;literal&amp;#34; strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\r\n`).  When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size.  When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues.  The server does not need to send any more data.  There is no limit on the size of literals that will be accepted.&lt;/p&gt;
&lt;p&gt;### Fix
#### Upgrade
Users should upgrade to `net-imap` 0.5.7 or later.  A configurable `max_response_size` limit has been added to `Net::IMAP`&amp;#39;s response reader.  The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.&lt;/p&gt;
&lt;p&gt;To set a global value for `max_response_size`, users must upgrade to `net-imap` ~&amp;gt; 0.4.20, or &amp;gt; 0.5.7.&lt;/p&gt;
&lt;p&gt;#### Configurat…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-j3g3-5qv5-52mj</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-43857 — net-imap rubygem vulnerable to possible DoS by memory exhaustion</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-43857</link>
      <description>msrc_CVE-2025-43857</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-43857</guid>
    </item>
    <item>
      <title>OESA-2025-1640 — ruby security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1640</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: ruby, openEuler:22.03-LTS-SP4: ruby, openEuler:24.03-LTS: ruby, openEuler:24.03-LTS-SP1: ruby, openEuler:20.03-LTS-SP4: ruby&lt;/p&gt;
&lt;p&gt;Ruby is a fast and easy interpreted scripting language for object-oriented programming. It has many functions for processing text Files and perform system management tasks (such as Perl).&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &amp;amp;quot;literal&amp;amp;quot; byte count, which is automatically read by the client&amp;amp;apos;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.(CVE-2025-43857)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: ruby, openEuler:22.03-LTS-SP4: ruby, openEuler:24.03-LTS: ruby, openEuler:24.03-LTS-SP1: ruby, openEuler:20.03-LTS-SP4: ruby&lt;/p&gt;
&lt;p&gt;Ruby is a fast and easy interpreted scripting language for object-oriented programming. It has many functions for processing text Files and perform system management tasks (such as Perl).&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &amp;amp;quot;literal&amp;amp;quot; byte count, which is automatically read by the client&amp;amp;apos;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.(CVE-2025-43857)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1640</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-43857</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-43857</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: jruby, Ubuntu:16.04:LTS: jruby, Ubuntu:Pro:18.04:LTS: ruby2.5, Ubuntu:18.04:LTS: jruby, Ubuntu:Pro:20.04:LTS: ruby2.7, Ubuntu:20.04:LTS: jruby, Ubuntu:22.04:LTS: ruby3.0, Ubuntu:24.04:LTS: jruby, Ubuntu:24.04:LTS: ruby3.2, Ubuntu:25.10: jruby and 3 more&lt;/p&gt;
&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: jruby, Ubuntu:16.04:LTS: jruby, Ubuntu:Pro:18.04:LTS: ruby2.5, Ubuntu:18.04:LTS: jruby, Ubuntu:Pro:20.04:LTS: ruby2.7, Ubuntu:20.04:LTS: jruby, Ubuntu:22.04:LTS: ruby3.0, Ubuntu:24.04:LTS: jruby, Ubuntu:24.04:LTS: ruby3.2, Ubuntu:25.10: jruby and 3 more&lt;/p&gt;
&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &amp;#34;literal&amp;#34; byte count, which is automatically read by the client&amp;#39;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-43857</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0914 — Ruby: Schwachstelle ermöglicht Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0914</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Ruby ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann eine Schwachstelle in Ruby ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0914</guid>
    </item>
  </channel>
</rss>
