CVE-2024-12797
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:LSummary
CVE-2024-12797 is a medium-severity Missing Report of Error Condition (CWE-392) vulnerability in Openssl Library (inferred from references). Its CVSS base score is 6.3 (Medium).
Operationally, ranked in the top 17% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-51115
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Mandates alerting on audit failures, directly providing the missing report of the error condition.
Reporting the security and privacy status to organizational officials ensures monitoring and assessment results are communicated rather than omitted.
Requires reporting and escalation of error conditions and incidents per documented procedures.
IR testing would expose missing error reporting that prevents timely incident detection and response.
Offers direct support for reporting incidents, addressing the failure to report error conditions or security events.
Includes explicit reporting of security status and analysis results, addressing missing reports of error or monitoring conditions.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Requiring log generation directly forces error conditions to be reported so they become visible to monitoring.
Secure SDLC practices include explicit coding standards for reporting all error conditions.
Runtime monitoring can surface unreported errors only if the underlying code already emits them.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can identify missing error reporting through negative test cases and exception handling checks.
Logging of errors and exceptions helps ensure that error conditions are captured and reported.
Monitoring activities can detect missing error reporting by observing abnormal system behavior.
Secure development lifecycle practices include requirements for proper error handling and status reporting.
Application security requirements typically mandate explicit error condition reporting to calling components.
Secure coding standards require functions to return appropriate error codes or status values.