<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 21:36:15 +0000</lastBuildDate>
    <item>
      <title>BREW-imap-backup-CVE-2026-42246 — net-imap vulnerable to STARTTLS stripping via invalid response timing</title>
      <link>https://vulnerability.circl.lu/vuln/brew-imap-backup-cve-2026-42246</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: imap-backup&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return &amp;#34;successfully&amp;#34;, without starting TLS.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes &amp;#34;successfully&amp;#34; before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.&lt;/p&gt;
&lt;p&gt;This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;TLS bypass, leading to cleartext transmission of sensitive information.&lt;/p&gt;
&lt;p&gt;### Mitigation&lt;/p&gt;
&lt;p&gt;* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.
* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.
  This is strongly recommended anyway:
  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connec…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: imap-backup&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return &amp;#34;successfully&amp;#34;, without starting TLS.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes &amp;#34;successfully&amp;#34; before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.&lt;/p&gt;
&lt;p&gt;This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;TLS bypass, leading to cleartext transmission of sensitive information.&lt;/p&gt;
&lt;p&gt;### Mitigation&lt;/p&gt;
&lt;p&gt;* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.
* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.
  This is strongly recommended anyway:
  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connec…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/brew-imap-backup-cve-2026-42246</guid>
    </item>
    <item>
      <title>CLEANSTART-2026-FA36805 — Security fix for ghsa-vcgp-9326-pqcp applied in: ruby-fluentd-1.19 1.19.2-r2</title>
      <link>https://vulnerability.circl.lu/vuln/cleanstart-2026-fa36805</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: ruby-fluentd-1.19&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the ruby-fluentd-1.19 package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: ruby-fluentd-1.19&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the ruby-fluentd-1.19 package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cleanstart-2026-fa36805</guid>
    </item>
    <item>
      <title>CVE-2026-42246 — net-imap vulnerable to STARTTLS stripping via invalid response timing</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-42246</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; ruby net-imap, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 7 Extended Lifecycle Support, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On, Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.6 Extended Update Support Long-Life Add-On, Red Hat Enterprise Linux 8.8 Telecommunications Update Service and 9 more&lt;/p&gt;
&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4, a man-in-the-middle attacker can cause Net::IMAP#starttls to return &amp;#34;successfully&amp;#34;, without starting TLS. This issue has been patched in versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; ruby net-imap, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 7 Extended Lifecycle Support, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On, Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.6 Extended Update Support Long-Life Add-On, Red Hat Enterprise Linux 8.8 Telecommunications Update Service and 9 more&lt;/p&gt;
&lt;p&gt;Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4, a man-in-the-middle attacker can cause Net::IMAP#starttls to return &amp;#34;successfully&amp;#34;, without starting TLS. This issue has been patched in versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-42246</guid>
    </item>
  </channel>
</rss>
