CVE-2026-45388

Vulnerability

In OCaml-TLS versions prior to 2.1.0, the TLS 1.3 client implementation (handshake_client13.ml) fails to check the ExtendedKeyUsage and KeyUsage extensions of the server's leaf certificate. The TLS 1.2 code path (handshake_client.ml) correctly validates that the certificate includes id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1), but this check was not ported to the new TLS 1.3 handshake function answer_certificate. As a result, any certificate that chains to a trusted CA and has a Subject Alternative Name (SAN) matching the target hostname is accepted, even if its Extended Key Usage only permits client authentication, code signing, or other non-server purposes. [1]

Exploitation

An attacker needs a certificate that is not intended for TLS server authentication (e.g., a client authentication certificate from a corporate PKI, a code signing certificate, or an S/MIME certificate) but that contains a DNS SAN matching the hostname the OCaml-TLS client intends to connect to. The attacker must also be in a position to intercept or redirect the client's TLS connection (e.g., on the same network, via DNS spoofing, or by compromising a router). During the TLS 1.3 handshake, the attacker presents this certificate as the server's leaf certificate. The OCaml-TLS client verifies the certificate chain and signature but does not enforce the Extended Key Usage constraint, so the handshake succeeds. [1]

Impact

A successful attack allows the adversary to impersonate any server hostname to an OCaml-TLS client using TLS 1.3. This can lead to man-in-the-middle attacks, interception of sensitive data, and injection of malicious content. The attacker gains the ability to decrypt and modify application-layer traffic, effectively compromising the confidentiality and integrity of the TLS session. The client believes it is communicating with the legitimate server, while the attacker controls the connection. [1]

Mitigation

The vulnerability is fixed in OCaml-TLS version 2.1.0. Users should upgrade to this version or later. No workaround is available for versions prior to 2.1.0. The issue is not currently listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. [1]