<?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>Thu, 01 Oct 2026 14:16:30 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-3634</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2021-3634</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; libssh&lt;/p&gt;
&lt;p&gt;A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secret_hash and the other session_id. Initially, both of them are the same, but after key re-exchange, previous session_id is kept and used as an input to new secret_hash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating &amp;#34;secret_hash&amp;#34; of different size than the session_id has. This becomes an issue when the session_id memory is zeroed or when it is used again during second key re-exchange.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; libssh&lt;/p&gt;
&lt;p&gt;A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secret_hash and the other session_id. Initially, both of them are the same, but after key re-exchange, previous session_id is kept and used as an input to new secret_hash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating &amp;#34;secret_hash&amp;#34; of different size than the session_id has. This becomes an issue when the session_id memory is zeroed or when it is used again during second key re-exchange.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2021-3634</guid>
    </item>
    <item>
      <title>USN-5053-1 — libssh vulnerability</title>
      <link>https://vulnerability.circl.lu/vuln/usn-5053-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: libssh&lt;/p&gt;
&lt;p&gt;It was discovered that libssh incorrectly handled rekeying. A remote
attacker could use this issue to cause libssh to crash, resulting in a
denial of service, or possibly execute arbitrary code.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: libssh&lt;/p&gt;
&lt;p&gt;It was discovered that libssh incorrectly handled rekeying. A remote
attacker could use this issue to cause libssh to crash, resulting in a
denial of service, or possibly execute arbitrary code.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/usn-5053-1</guid>
    </item>
  </channel>
</rss>
