<?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>Thu, 15 Oct 2026 05:41:19 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-12797 — RFC7250 handshakes with unauthenticated servers don't abort as expected</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2024-12797</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; OpenSSL&lt;/p&gt;
&lt;p&gt;Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a
server may fail to notice that the server was not authenticated, because
handshakes don&amp;#39;t abort as expected when the SSL_VERIFY_PEER verification mode
is set.&lt;/p&gt;
&lt;p&gt;Impact summary: TLS and DTLS connections using raw public keys may be
vulnerable to man-in-middle attacks when server authentication failure is not
detected by clients.&lt;/p&gt;
&lt;p&gt;RPKs are disabled by default in both TLS clients and TLS servers.  The issue
only arises when TLS clients explicitly enable RPK use by the server, and the
server, likewise, enables sending of an RPK instead of an X.509 certificate
chain.  The affected clients are those that then rely on the handshake to
fail when the server&amp;#39;s RPK fails to match one of the expected public keys,
by setting the verification mode to SSL_VERIFY_PEER.&lt;/p&gt;
&lt;p&gt;Clients that enable server-side raw public keys can still find out that raw
public key verification failed by calling SSL_get_verify_result(), and those
that do, and take appropriate action, are not affected.  This issue was
introduced in the initial implementation of RPK support in OpenSSL 3.2.&lt;/p&gt;
&lt;p&gt;The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; OpenSSL&lt;/p&gt;
&lt;p&gt;Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a
server may fail to notice that the server was not authenticated, because
handshakes don&amp;#39;t abort as expected when the SSL_VERIFY_PEER verification mode
is set.&lt;/p&gt;
&lt;p&gt;Impact summary: TLS and DTLS connections using raw public keys may be
vulnerable to man-in-middle attacks when server authentication failure is not
detected by clients.&lt;/p&gt;
&lt;p&gt;RPKs are disabled by default in both TLS clients and TLS servers.  The issue
only arises when TLS clients explicitly enable RPK use by the server, and the
server, likewise, enables sending of an RPK instead of an X.509 certificate
chain.  The affected clients are those that then rely on the handshake to
fail when the server&amp;#39;s RPK fails to match one of the expected public keys,
by setting the verification mode to SSL_VERIFY_PEER.&lt;/p&gt;
&lt;p&gt;Clients that enable server-side raw public keys can still find out that raw
public key verification failed by calling SSL_get_verify_result(), and those
that do, and take appropriate action, are not affected.  This issue was
introduced in the initial implementation of RPK support in OpenSSL 3.2.&lt;/p&gt;
&lt;p&gt;The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2024-12797</guid>
    </item>
    <item>
      <title>USN-7264-1 — openssl vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-7264-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.10: openssl&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL clients incorrectly handled authenticating
servers using RFC7250 Raw Public Keys. In certain cases, the connection
will not abort as expected, possibly causing the communication to be
intercepted. (CVE-2024-12797)&lt;/p&gt;
&lt;p&gt;George Pantelakis and Alicja Kario discovered that OpenSSL had a timing
side-channel when performing ECDSA signature computations. A remote
attacker could possibly use this issue to recover private data.
(CVE-2024-13176)&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL incorrectly handled certain memory
operations when using low-level GF(2^m) elliptic curve APIs with untrusted
explicit values for the field polynomial. When being used in this uncommon
fashion, a remote attacker could use this issue to cause OpenSSL to crash,
resulting in a denial of service, or possibly execute arbitrary code.
(CVE-2024-9143)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.10: openssl&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL clients incorrectly handled authenticating
servers using RFC7250 Raw Public Keys. In certain cases, the connection
will not abort as expected, possibly causing the communication to be
intercepted. (CVE-2024-12797)&lt;/p&gt;
&lt;p&gt;George Pantelakis and Alicja Kario discovered that OpenSSL had a timing
side-channel when performing ECDSA signature computations. A remote
attacker could possibly use this issue to recover private data.
(CVE-2024-13176)&lt;/p&gt;
&lt;p&gt;It was discovered that OpenSSL incorrectly handled certain memory
operations when using low-level GF(2^m) elliptic curve APIs with untrusted
explicit values for the field polynomial. When being used in this uncommon
fashion, a remote attacker could use this issue to cause OpenSSL to crash,
resulting in a denial of service, or possibly execute arbitrary code.
(CVE-2024-9143)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-7264-1</guid>
    </item>
  </channel>
</rss>
