CVE-2024-12797

Published Feb 11, 2025

Last updated 3 months ago

CVSS medium 6.3
Tls

Overview

AI description

Automated description summarized from trusted sources.

CVE-2024-12797 is a vulnerability in OpenSSL related to the implementation of Raw Public Keys (RPKs), an alternative to traditional X.509 certificates for authentication. The flaw allows attackers to potentially execute man-in-the-middle (MITM) attacks by impersonating servers. Clients using RPKs for server authentication might not detect the impersonation because handshakes don't terminate as expected when the SSL\_VERIFY\_PEER verification mode is active. The vulnerability affects OpenSSL versions 3.2, 3.3, and 3.4. Recommended remediation involves updating to OpenSSL 3.2.4, 3.3.2, or 3.4.1, respectively. The vulnerability doesn't affect OpenSSL versions 3.0, 3.1, 1.1.1, 1.0.2, or FIPS modules. The issue was initially reported to OpenSSL by Apple Inc. in December 2024. The cryptography package, which includes OpenSSL, is also impacted by this vulnerability, and updating to version 44.0.1 or later is advised. If immediate updates are not feasible, building from source is a suggested temporary workaround.

Description
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't abort as expected when the SSL_VERIFY_PEER verification mode is set. 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. 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's RPK fails to match one of the expected public keys, by setting the verification mode to SSL_VERIFY_PEER. 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. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
Source
openssl-security@openssl.org
NVD status
Deferred

Risk scores

CVSS 3.1

Type
Secondary
Base score
6.3
Impact score
3.4
Exploitability score
2.8
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
Severity
MEDIUM

Weaknesses

openssl-security@openssl.org
CWE-392

Social media

Hype score
Not currently trending

  1. New critical CVEs in 'cryptography' (CVE-2024-12797, CVE-2026-26007, CVE-2026-34073, July 8) expose TLS/DNS to MITM & forgery. Immediate patching vital for data privacy & integrity in transit. #Cybersecurity #News

    @YourAnon_irc

    9 Jul 2026

    75 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. ⚠️ CVE-2024-12797: OpenSSL Vulnerable a Ataques MitM por Falla en Raw Public Key Authentication https://t.co/dHYAe8hFHg

    @tpx_Security

    14 Feb 2025

    65 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. 📢OpenSSL ออกแพตช์แก้ไขช่องโหว่ CVE-2024-12797🛠️ #ThaiCERT #NCSA #CybersecurityNew สามารถติดตามข่าวสารได้ที่ https://t.co/HCsLrrYz4c https://t.co/QEsxfJrHjV

    @ThaiCERTByNCSA

    13 Feb 2025

    7 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. آسیب پذیری جدیدی از نوع mitm برای محصول openssl با کد شناسایی CVE-2024-12797 منتشر شده. نسخه های 3.4 و 3.3 و 3.2 و نسخه های پایین تر از این نسخه ها دارای این آسیب پذیری می باشند. برای پیشگیری به ترتیب به نسخه های 3.4.1 و 3.3.2 و 3.2.4 به روز رسانی‌کنید. https://t.co/Poz3aKY03t ht

    @AmirHossein_sec

    12 Feb 2025

    25 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. High-Severity OpenSSL Vulnerability Found by Apple Allows MitM Attacks (CVE-2024-12797) https://t.co/nrk5yRkYrB #patchmanagement

    @eyalestrin

    12 Feb 2025

    10 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. CVE-2024-12797 OpenSSL Vulnerability Patched #OpenSSH #CVE-2024-12797 https://t.co/06csGMk2J0

    @pravin_karthik

    12 Feb 2025

    69 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. CVE-2024-12797 – High-Severity OpenSSL Flaw: Update Now to Prevent MITM Attacks https://t.co/9GDr2GYiXY

    @Dinosn

    12 Feb 2025

    3120 Impressions

    11 Retweets

    33 Likes

    10 Bookmarks

    0 Replies

    0 Quotes

  8. High-Severity OpenSSL Vulnerability CVE-2024-12797 The vulnerability identified by Apple in OpenSSL, tracked as CVE-2024-12797, is indeed a high-severity issue that poses significant risks, especially in terms of Man-in-the-Middle (MitM) attacks. https://t.co/9e9kXsEXlf

    @roytrilok91

    12 Feb 2025

    56 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  9. 🚨Alert🚨 CVE-2024-12797:OpenSSL TLS/DTLS Raw Public Key Authentication Failure 📊 71M+ Services are found on the https://t.co/ysWb28Crld yearly. 🔗Hunter Link:https://t.co/BcOtWFMO4G 👇Query HUNTER : https://t.co/q9rtuGgxk7="OpenSSL" FOFA : product="OpenSSL"… https://t.co/ddVUW

    @HunterMapping

    12 Feb 2025

    1536 Impressions

    5 Retweets

    25 Likes

    9 Bookmarks

    0 Replies

    0 Quotes

  10. OpenSSL 3.4.1 > a #security patch release. The most severe #CVE fixed in this release is High. This release incorporates the following bug fixes and mitigations: * Fixed CVE-2024-12797 * Fixed CVE-2024-13176 Details: https://t.co/EvRW7LB7gR

    @stevematindi

    12 Feb 2025

    8 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  11. OpenSSLで中間者攻撃を可能とする深刻な脆弱性が修正された。CVE-2024-12797はサーバ認証にRFC7250のraw形式公開鍵(RPK)を使用しているクライアント向けで、同機能が実装されたバージョン3.2での作り込み。同機能は既定では無効。 https://t.co/GKAraVOI5U SSL_VERIFY_PEERを設定していても… https://t.co/Ipie8gnAmR

    @__kokumoto

    11 Feb 2025

    4136 Impressions

    25 Retweets

    65 Likes

    19 Bookmarks

    0 Replies

    0 Quotes

  12. OpenSSL patched high-severity flaw CVE-2024-12797 https://t.co/eGxGCyNMxr

    @hackplayers

    11 Feb 2025

    665 Impressions

    4 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  13. SIOSセキュリティブログを更新しました。 OpenSSLの脆弱性(High: CVE-2024-12797, Low: CVE-2024-13176) #sios_tech #security #vulnerability #セキュリティ #脆弱性 #linux #openssl https://t.co/nkfkBZnIKE

    @omokazuki

    11 Feb 2025

    93 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  14. CVE-2024-12797 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'… https://t.co/HOZukk25TU

    @CVEnew

    11 Feb 2025

    12 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Related CVEs

  1. Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag. This enables selective suppression of application data. In HTTP pipelining scenarios, dropping a TLS record containing an HTTP request can cause request/response desynchronization, where subsequent responses are delivered to the wrong requests. In write-heavy workloads, a dropped record containing a write request can result in undetectable data loss when the client interprets a subsequent success response as confirmation of the dropped write. All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16317
  2. The QUIC transport parameters extension handler in s2n-tls incorrectly uses s2n_alloc instead of s2n_realloc to store the peer's transport parameters. When a TLS 1.3 connection goes through a HelloRetryRequest, the handler is called twice on the same connection. On the second call, s2n_alloc zeroes the existing pointer before allocating new memory, causing the first allocation to be leaked. This can occur during normal QUIC traffic when a client offers a key share group the server does not prefer. An unauthenticated user can amplify the issue by deliberately forcing HelloRetryRequests, causing up to approximately 64 KB of unreachable memory per handshake. Over time, this can lead to increased memory consumption on long-running server processes. The unreachable memory is only reclaimed when the process is restarted. Only server-side QUIC-enabled deployments are affected. Non-QUIC TLS connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16318
  3. In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty "requests" list onto hn->hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice each req->hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than list_del() in the drain so req->hr_list does not carry LIST_POISON after drain releases the entry. The DRAINING guard in remove_pending() makes cancel return false, but cancel still falls through to test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference. Without another pin, if that is the last reference, sk_destruct frees the request while it is still linked on the drain loop's local list. Pin each request's hr_file under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request.•CVE-2026-63978
  4. Bypass to the fix for CVE-2026-34916. Variants of such vectors have been also reported by phucrio and offsetmd. The fix can be bypassed either by sending a disallowed but otherwise valid plugin identifier as `type`, or using the `ox.setChannelTargeting` XML-RPC API method.•CVE-2026-50741
  5. A flaw in Node.js WebCrypto implementation can crash the process if the input of `subtle.encrypt()` is a multiple of 2GiB. This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**.•CVE-2026-48933

References

Sources include official advisories and independent security research.