CVE-2024-12797

What it actually does

OpenSSL clients that explicitly enable RFC 7250 Raw Public Keys for server authentication may continue a TLS or DTLS handshake even when the server raw public key does not match the expected key, despite SSL_VERIFY_PEER being configured. The failure is still available through SSL_get_verify_result(), so applications that explicitly check that result and reject failures are not affected. The issue is limited to client use of server-side raw public keys; conventional X.509 certificate-chain validation and OpenSSL FIPS modules are not affected. The practical technical impact is a server-authentication bypass that can enable man-in-the-middle interception, traffic modification, and connection disruption for affected TLS/DTLS clients.

Why it matters to the business

Organizations using OpenSSL-based clients with raw public key authentication can lose assurance that they are connecting to the intended server. In exposed use cases, an attacker positioned on the network path could intercept or alter sensitive communications, causing confidentiality, integrity, and availability impacts. The overall urgency is moderated by the fact that raw public keys are disabled by default, require explicit application support on both client and server, there is no CISA KEV listing, ransomware use is not reported, and EPSS is low; however, affected embedded, IoT, service-to-service, or specialized protocol deployments should still prioritize remediation because exploitation may not leave clear forensic evidence.

How an attack unfolds

An attacker first needs a position where they can observe or influence traffic between an affected client and its intended TLS or DTLS server, such as a compromised network segment, malicious access point, DNS/BGP manipulation, gateway compromise, or local network man-in-the-middle. The target client must be built with an affected OpenSSL version, explicitly allow the server to authenticate with an RFC 7250 raw public key, and rely on SSL_VERIFY_PEER to abort the handshake when the server key does not match an expected key. The attacker presents or relays a server endpoint using an unexpected raw public key. Due to the flaw, the client handshake may not fail as the application expects. If the application does not call SSL_get_verify_result() and enforce failure handling, it may treat the connection as authenticated. The attacker can then proxy, read, modify, inject, or selectively drop application traffic over the supposedly protected TLS/DTLS channel.

How to fix it

Upgrade OpenSSL to a fixed build that includes commit 738d4f9fdeaad57660dcba50a619fafced3fd5e9 or a vendor release that incorporates that fix. Where package managers or operating-system vendors supply OpenSSL, apply the vendor security update rather than building directly from source unless that is the established maintenance model. If immediate patching is not possible, disable RFC 7250 raw public key authentication where it is not strictly required, use standard X.509 certificate-chain authentication instead, or modify affected applications to explicitly call SSL_get_verify_result() after the handshake and terminate the connection unless verification succeeds. Review client code paths that configure SSL_VERIFY_PEER together with server raw public key support, especially in custom clients, embedded products, IoT software, service meshes, and DTLS-based applications. OpenSSL FIPS modules for 3.4, 3.3, 3.2, 3.1, and 3.0 are not affected by this issue, but applications using the non-FIPS TLS stack with RPK support still require review.

How to confirm the fix worked

Confirm deployed OpenSSL versions and vendor advisories to verify that the fixed commit or an equivalent patched release is present. Inventory application code and binaries for RFC 7250 raw public key usage and SSL_VERIFY_PEER configuration. Validate behavior with a negative test: configure a test TLS/DTLS server to present a raw public key that is not in the client’s expected key set and confirm that the client rejects the connection. If the application intentionally supports raw public keys, verify that it checks SSL_get_verify_result() and fails closed on any verification error. For source builds, confirm the OpenSSL source tree contains commit 738d4f9fdeaad57660dcba50a619fafced3fd5e9 or equivalent changes. For runtime validation, use dependency scanning, software composition analysis, package inventory, and targeted integration tests rather than relying only on network scanning, because RPK use is application-specific and disabled by default.

Typical attack path

1. Identify a target application or device using OpenSSL 3.2 or later with RFC 7250 raw public key server authentication enabled.
2. Gain an on-path position between the client and the legitimate server through local network access, routing manipulation, DNS manipulation, or infrastructure compromise.
3. Initiate or intercept the TLS/DTLS connection and present a raw public key that does not match the client’s expected server key.
4. Rely on the vulnerable client behavior where SSL_VERIFY_PEER does not abort the handshake as expected after raw public key verification failure.
5. If the application fails to check SSL_get_verify_result() and terminate the connection, establish a man-in-the-middle session.
6. Read, modify, replay, inject, or disrupt traffic carried over the affected TLS/DTLS connection.

How to detect it

There are no universal, reliable indicators of exploitation because successful abuse looks like a TLS/DTLS connection that the vulnerable application incorrectly accepted. Detection should combine exposure hunting, network-path anomaly review, and application-specific logging. Search source code, build artifacts, and configuration for RFC 7250 raw public key support, server certificate type settings, and SSL_VERIFY_PEER usage without an accompanying SSL_get_verify_result() enforcement check. Review application logs for verification failures that did not result in connection termination, unexpected peer key fingerprints, server key changes, or authentication warnings around TLS/DTLS session establishment. Network teams should review evidence of man-in-the-middle positioning during relevant time windows, including ARP spoofing alerts, duplicate IP/MAC events, rogue DHCP or DNS responses, unexpected gateway changes, wireless evil-twin detections, BGP/route anomalies, and TLS telemetry showing raw public key negotiation with unexpected peers. If packet capture or TLS metadata is available, compare observed raw public key fingerprints against the expected allowlist for the application. Because the vulnerability affects authentication semantics inside the client, absence of logs does not prove absence of exploitation.

What your security team should do

• Prioritize identifying applications that explicitly enable RFC 7250 raw public keys with OpenSSL, because default OpenSSL TLS clients and ordinary X.509 certificate validation are not the primary exposure.
• Patch OpenSSL through vendor-supported updates or rebuild affected applications against a fixed OpenSSL containing commit 738d4f9fdeaad57660dcba50a619fafced3fd5e9.
• For applications that must continue using raw public keys, require an explicit SSL_get_verify_result() check after handshake completion and fail closed on verification failure.
• Temporarily disable raw public key server authentication or migrate to X.509 certificate validation where operationally feasible.
• Focus review on embedded, IoT, appliance, DTLS, and custom service-to-service clients where raw public keys are more likely to be used.
• Add regression tests that attempt connections to servers presenting unexpected raw public keys and verify that clients reject them.
• Monitor for network-path attack prerequisites, including unexpected DNS changes, ARP spoofing, rogue wireless access points, abnormal gateway behavior, and unusual certificate-type negotiation if TLS telemetry is available.
• Treat suspected exploitation as a potential confidentiality and integrity incident because successful abuse may allow traffic interception without a distinctive host artifact.