CVE-2024-45159 in mbed TLS
Summary
by MITRE • 09/05/2024
An issue was discovered in Mbed TLS 3.x before 3.6.1. With TLS 1.3, when a server enables optional authentication of the client, if the client-provided certificate does not have appropriate values in if keyUsage or extKeyUsage extensions, then the return value of mbedtls_ssl_get_verify_result() would incorrectly have the MBEDTLS_X509_BADCERT_KEY_USAGE and MBEDTLS_X509_BADCERT_KEY_USAGE bits clear. As a result, an attacker that had a certificate valid for uses other than TLS client authentication would nonetheless be able to use it for TLS client authentication. Only TLS 1.3 servers were affected, and only with optional authentication (with required authentication, the handshake would be aborted with a fatal alert).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 06/06/2026
This vulnerability in Mbed TLS 3.x versions prior to 3.6.1 represents a critical cryptographic validation flaw that undermines the integrity of TLS 1.3 client authentication mechanisms. The issue specifically affects servers that configure optional client certificate authentication, where the certificate validation process fails to properly enforce key usage restrictions. When a client presents a certificate that lacks appropriate values in the keyUsage or extended keyUsage extensions for TLS client authentication, the cryptographic library incorrectly clears the verification error bits that should indicate certificate validation failure. This fundamental flaw creates a pathway for attackers to exploit weak certificate permissions and gain unauthorized access to TLS-protected services. The vulnerability operates at the core of X.509 certificate validation logic, where the expected behavior should enforce strict adherence to certificate purpose restrictions as defined by the PKIX standards and RFC 5280. The technical implementation error manifests in the mbedtls_ssl_get_verify_result() function, which is responsible for returning certificate validation status codes that applications rely upon for access control decisions.
The operational impact of this vulnerability extends beyond simple authentication bypass to potentially compromise the entire TLS security model. In environments where TLS client certificates are used for access control, such as enterprise applications, API gateways, and secure remote access systems, an attacker with a certificate valid for non-TLS purposes could successfully authenticate as a client. This scenario particularly affects systems where certificate-based authentication is implemented without additional verification layers, creating a dangerous condition where certificate permissions are not properly enforced. The vulnerability is particularly concerning because it only affects optional client authentication scenarios, meaning that when required authentication is enforced, the handshake would properly fail with a fatal alert. However, in configurations where optional authentication is enabled, the system would incorrectly accept certificates that should be rejected based on their key usage constraints, effectively bypassing a critical security control. This behavior directly violates the principle of least privilege and undermines the trust model that TLS client authentication is designed to establish.
The security implications of CVE-2024-45159 align with several ATT&CK framework techniques including T1552.001 (Unsecured Credentials) and T1078.004 (Valid Accounts). The vulnerability creates a condition where attackers can leverage certificates with inappropriate key usage to establish unauthorized TLS connections, potentially gaining access to sensitive systems or data. From a CWE perspective, this represents a weakness in validation of certificate extensions, specifically CWE-259 (Use of Hard-coded Password) and CWE-312 (Sensitive Data Exposure), though more accurately it aligns with CWE-311 (Missing Encryption of Sensitive Data) and CWE-310 (Cryptographic Issues) due to the improper enforcement of cryptographic validation. The flaw demonstrates a failure in proper certificate path validation as defined by RFC 5280, where the key usage extension should be strictly enforced to prevent certificates from being used outside their intended cryptographic purposes. Organizations using Mbed TLS 3.x versions before 3.6.1 should immediately assess their TLS client authentication configurations, particularly those employing optional client authentication, to identify systems vulnerable to this attack vector. The vulnerability's impact is particularly severe in environments where certificate-based access control is critical, such as financial services, healthcare systems, and government networks where unauthorized access could result in significant data breaches or system compromise.
Mitigation strategies should focus on immediate patching of Mbed TLS to version 3.6.1 or later, which contains the corrected certificate validation logic. System administrators should also implement additional monitoring for TLS client authentication events to detect potential exploitation attempts. Organizations should review their certificate management policies to ensure that certificates issued for TLS client authentication properly include the required keyUsage and extended keyUsage extensions. Network segmentation and additional authentication layers should be implemented as compensating controls while awaiting patch deployment. Security teams should conduct comprehensive audits of all TLS services that utilize optional client authentication, particularly those serving sensitive data or critical infrastructure components. The vulnerability highlights the importance of proper cryptographic library maintenance and the need for thorough testing of authentication mechanisms before deployment in production environments. Regular security assessments should include verification of certificate validation logic to prevent similar issues from arising in other cryptographic libraries or custom implementations. Organizations should also consider implementing certificate pinning or additional certificate validation checks beyond the standard library validation to provide defense in depth against such cryptographic validation failures.