<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T22:37:02.153039+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-2673</id>
    <title>CVE-2026-2673 — OpenSSL TLS 1.3 server may choose unexpected key agreement group</title>
    <updated>2026-09-29T22:37:02.157211+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> OpenSSL, Siemens SIMATIC CN 4100</p>
<p>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 'DEFAULT' keyword.</p>
<p>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'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.</p>
<p>If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' 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
'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
were treated as a single sufficiently secure 'tuple', with the server not
sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
was mutually supported.</p>
<p>As a result, the client and server might fail to negotiate a mutually supported
post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
configuration results in only 'classical' groups (such as 'X25519' being the
only ones in the client's initial keyshare prediction).</p>
<p>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…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-2673"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/usn-8155-1</id>
    <title>USN-8155-1 — openssl vulnerabilities</title>
    <updated>2026-09-29T22:37:02.157460+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:22.04:LTS: openssl, Ubuntu:24.04:LTS: openssl, Ubuntu:25.10: openssl</p>
<p>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)</p>
<p>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)</p>
<p>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)</p>
<p>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)</p>
<p>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)</p>
<p>Quoc Tran discovered that OpenSSL incorrectly handled hexadecimal
conversion on 32-bi…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/usn-8155-1"/>
  </entry>
</feed>
