<?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 22:37:01 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-2673 — OpenSSL TLS 1.3 server may choose unexpected key agreement group</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-2673</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; OpenSSL, Siemens SIMATIC CN 4100&lt;/p&gt;
&lt;p&gt;Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
preferred key exchange group when its key exchange group configuration includes
the default by using the &amp;#39;DEFAULT&amp;#39; keyword.&lt;/p&gt;
&lt;p&gt;Impact summary: A less preferred key exchange may be used even when a more
preferred group is supported by both client and server, if the group
was not included among the client&amp;#39;s initial predicated keyshares.
This will sometimes be the case with the new hybrid post-quantum groups,
if the client chooses to defer their use until specifically requested by
the server.&lt;/p&gt;
&lt;p&gt;If an OpenSSL TLS 1.3 server&amp;#39;s configuration uses the &amp;#39;DEFAULT&amp;#39; keyword to
interpolate the built-in default group list into its own configuration, perhaps
adding or removing specific elements, then an implementation defect causes the
&amp;#39;DEFAULT&amp;#39; list to lose its &amp;#39;tuple&amp;#39; structure, and all server-supported groups
were treated as a single sufficiently secure &amp;#39;tuple&amp;#39;, with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.&lt;/p&gt;
&lt;p&gt;As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as &amp;#39;X25519MLKEM768&amp;#39;, if the client&amp;#39;s
configuration results in only &amp;#39;classical&amp;#39; groups (such as &amp;#39;X25519&amp;#39; being the
only ones in the client&amp;#39;s initial keyshare prediction).&lt;/p&gt;
&lt;p&gt;OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
1.3 key agreement group on TLS servers.  The old syntax had a single…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; OpenSSL, Siemens SIMATIC CN 4100&lt;/p&gt;
&lt;p&gt;Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
preferred key exchange group when its key exchange group configuration includes
the default by using the &amp;#39;DEFAULT&amp;#39; keyword.&lt;/p&gt;
&lt;p&gt;Impact summary: A less preferred key exchange may be used even when a more
preferred group is supported by both client and server, if the group
was not included among the client&amp;#39;s initial predicated keyshares.
This will sometimes be the case with the new hybrid post-quantum groups,
if the client chooses to defer their use until specifically requested by
the server.&lt;/p&gt;
&lt;p&gt;If an OpenSSL TLS 1.3 server&amp;#39;s configuration uses the &amp;#39;DEFAULT&amp;#39; keyword to
interpolate the built-in default group list into its own configuration, perhaps
adding or removing specific elements, then an implementation defect causes the
&amp;#39;DEFAULT&amp;#39; list to lose its &amp;#39;tuple&amp;#39; structure, and all server-supported groups
were treated as a single sufficiently secure &amp;#39;tuple&amp;#39;, with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.&lt;/p&gt;
&lt;p&gt;As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as &amp;#39;X25519MLKEM768&amp;#39;, if the client&amp;#39;s
configuration results in only &amp;#39;classical&amp;#39; groups (such as &amp;#39;X25519&amp;#39; being the
only ones in the client&amp;#39;s initial keyshare prediction).&lt;/p&gt;
&lt;p&gt;OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
1.3 key agreement group on TLS servers.  The old syntax had a single…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-2673</guid>
    </item>
    <item>
      <title>USN-8155-1 — openssl vulnerabilities</title>
      <link>https://vulnerability.circl.lu/vuln/usn-8155-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: openssl, Ubuntu:24.04:LTS: openssl, Ubuntu:25.10: openssl&lt;/p&gt;
&lt;p&gt;Viktor Dukhovni discovered that OpenSSL incorrectly negotiated the expected
preferred key exchange group when used as a TLS 1.3 server. This could
result in a less preferred key exchange being used, contrary to
expectations. This issue only affected Ubuntu 25.10. (CVE-2026-2673)&lt;/p&gt;
&lt;p&gt;Igor Morgenstern discovered that OpenSSL incorrectly handled certain memory
operations when used as a DANE client. A remote attacker could use this
issue to cause OpenSSL to crash, resulting in a denial of service, or
possibly execute arbitrary code. (CVE-2026-28387)&lt;/p&gt;
&lt;p&gt;Igor Morgenstern discovered that OpenSSL incorrectly handled certain memory
operations when processing a delta CRL. A remote attacker could possibly
use this issue to cause OpenSSL to crash, resulting in a denial of service.
(CVE-2026-28388)&lt;/p&gt;
&lt;p&gt;Nathan Sportsman, Daniel Rhea, and Jaeho Nam discovered that OpenSSL
incorrectly handled certain memory operations when processing a crafted CMS
EnvelopedData message with KeyAgreeRecipientInfo. A remote attacker could
possibly use this issue to cause OpenSSL to crash, resulting in a denial
of service. (CVE-2026-28389)&lt;/p&gt;
&lt;p&gt;Muhammad Daffa, Joshua Rogers, and Chanho Kim discovered that OpenSSL
incorrectly handled processing of a crafted CMS EnvelopedData message with
KeyTransportRecipientInfo. A remote attacker could possibly use this issue
to cause OpenSSL to crash, resulting in a denial of service.
(CVE-2026-28390)&lt;/p&gt;
&lt;p&gt;Quoc Tran discovered that OpenSSL incorrectly handled hexadecimal
conversion on 32-bi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: openssl, Ubuntu:24.04:LTS: openssl, Ubuntu:25.10: openssl&lt;/p&gt;
&lt;p&gt;Viktor Dukhovni discovered that OpenSSL incorrectly negotiated the expected
preferred key exchange group when used as a TLS 1.3 server. This could
result in a less preferred key exchange being used, contrary to
expectations. This issue only affected Ubuntu 25.10. (CVE-2026-2673)&lt;/p&gt;
&lt;p&gt;Igor Morgenstern discovered that OpenSSL incorrectly handled certain memory
operations when used as a DANE client. A remote attacker could use this
issue to cause OpenSSL to crash, resulting in a denial of service, or
possibly execute arbitrary code. (CVE-2026-28387)&lt;/p&gt;
&lt;p&gt;Igor Morgenstern discovered that OpenSSL incorrectly handled certain memory
operations when processing a delta CRL. A remote attacker could possibly
use this issue to cause OpenSSL to crash, resulting in a denial of service.
(CVE-2026-28388)&lt;/p&gt;
&lt;p&gt;Nathan Sportsman, Daniel Rhea, and Jaeho Nam discovered that OpenSSL
incorrectly handled certain memory operations when processing a crafted CMS
EnvelopedData message with KeyAgreeRecipientInfo. A remote attacker could
possibly use this issue to cause OpenSSL to crash, resulting in a denial
of service. (CVE-2026-28389)&lt;/p&gt;
&lt;p&gt;Muhammad Daffa, Joshua Rogers, and Chanho Kim discovered that OpenSSL
incorrectly handled processing of a crafted CMS EnvelopedData message with
KeyTransportRecipientInfo. A remote attacker could possibly use this issue
to cause OpenSSL to crash, resulting in a denial of service.
(CVE-2026-28390)&lt;/p&gt;
&lt;p&gt;Quoc Tran discovered that OpenSSL incorrectly handled hexadecimal
conversion on 32-bi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/usn-8155-1</guid>
    </item>
  </channel>
</rss>
