HIGH 7.4

CVE-2026-45389: OCaml-TLS Client Certificate Validation Bypass (CVSS 7.4)

OCaml-TLS, a cryptographic library implementing TLS/SSL protocols, fails to properly validate client certificates before accepting them for authentication. An attacker can present a certificate that lacks the proper authorization markers (KeyUsage and ExtendedKeyUsage attributes) and still have it accepted by the server, enabling account takeover or credential impersonation in systems that rely on client certificate authentication.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.4 HIGH · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Weaknesses (CWE)
CWE-295
Affected products
0 configuration(s)
Published / Modified
2026-06-15 / 2026-06-17

NVD description (verbatim)

In OCaml-TLS before 2.1.0, the server implementation does insufficient checks of the certificate provided by the client (when doing client authentication), which allows impersonation with certificates that are not meant for client authentication (because of KeyUsage and ExtendedKeyUsage).

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-45389 is a certificate validation bypass in OCaml-TLS versions prior to 2.1.0. During mutual TLS (mTLS) authentication, the server accepts client certificates without sufficiently checking whether those certificates are actually marked for client authentication purposes. The KeyUsage and ExtendedKeyUsage X.509 extensions—critical fields that restrict certificate usage to specific purposes—are not properly enforced. This allows an attacker to reuse a general-purpose or server certificate (or similar misconfigured certificate) for client authentication, circumventing the intended access controls. The vulnerability maps to CWE-295 (Improper Certificate Validation).

Business impact

Systems using OCaml-TLS for client certificate authentication lose a critical trust boundary. An attacker holding any certificate signed by the same Certificate Authority can impersonate legitimate clients, potentially gaining unauthorized access to protected resources. In microservices architectures, cloud environments, or enterprises using certificate-based access control (zero-trust, mTLS), this creates a significant lateral movement vector. Confidentiality and integrity of client-server communications can be compromised, though availability is not directly affected.

Affected systems

OCaml-TLS library versions before 2.1.0 are vulnerable. This includes any application or service built on OCaml-TLS that performs client certificate authentication. Verify your dependency tree and supply chain; OCaml-TLS may be used as an indirect dependency in larger OCaml-based projects, containerized services, or embedded cryptographic stacks.

Exploitability

Exploitation requires the attacker to possess a certificate valid for the target Certificate Authority—a non-trivial precondition, but realistic in scenarios where CA compromise has occurred or where internal enterprise CAs issue broadly-purposed certificates. The attack is network-accessible and requires no user interaction or special privileges. Network complexity is rated as high, likely reflecting the need to intercept or initiate connections at the right endpoint. Overall CVSS 7.4 (HIGH) reflects meaningful but not maximum impact.

Remediation

Upgrade OCaml-TLS to version 2.1.0 or later. This release includes corrected certificate validation logic that enforces KeyUsage and ExtendedKeyUsage checks. After patching, conduct certificate audits to ensure all issued certificates contain appropriate extension constraints for their intended use cases.

Patch guidance

Update the OCaml-TLS dependency to version 2.1.0 as confirmed in the official vendor advisory. This is a security update and should be prioritized in your normal release cycle. Test the upgrade in a staging environment with client certificate authentication enabled to ensure no compatibility regressions. Rebuild and redeploy all affected services. No breaking changes are anticipated, but verify against OCaml-TLS release notes.

Detection guidance

Monitor TLS handshake logs and authentication events for any client certificates being accepted that lack proper KeyUsage or ExtendedKeyUsage markers. In mTLS deployments, audit the certificate chains presented by clients and cross-reference against your CA's issued certificate inventory. Look for unexpected certificate serial numbers or subjects connecting as clients. Network intrusion detection systems (IDS) may detect suspicious certificate chains if tuned to flag non-standard TLS parameters. Most reliably, enable detailed TLS session logging in your application and review for certificates that bypass expected validation gates.

Why prioritize this

This is a HIGH severity authentication bypass affecting certificate-based access control. Organizations heavily dependent on mTLS or client certificate authentication (particularly cloud-native, zero-trust, or federated identity systems) should prioritize this immediately. The attack requires Certificate Authority compromise or misissuance, which is a real risk in many enterprises. CVE-2026-45389 is not currently listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, but the core flaw is straightforward enough that attack tools or POC code could emerge quickly once public scrutiny increases.

Risk score, explained

CVSS 3.1 score of 7.4 (HIGH) reflects: Attack Vector Network (AV:N)—remotely exploitable; Attack Complexity High (AC:H)—requires attacker to hold a valid certificate; Privileges Required None (PR:N)—no prior access needed; User Interaction None (UI:N)—no social engineering; Scope Unchanged (S:U)—no privilege escalation; Confidentiality High (C:H), Integrity High (I:H)—client identity spoofing enables unauthorized access and data tampering; Availability None (A:N)—no denial of service. The score appropriately captures a serious authentication weakness that enables impersonation but does not directly affect service availability.

Frequently asked questions

Does OCaml-TLS 2.1.0 fix the issue completely?

Yes, version 2.1.0 introduces the necessary certificate validation logic to check KeyUsage and ExtendedKeyUsage extensions during client authentication. Verify against the official OCaml-TLS changelog to confirm the fix is present in any patch or maintenance releases based on 2.1.0.

Which applications are most at risk?

OCaml services using client certificate authentication are at risk. This includes secure microservices, mTLS-enabled infrastructure, internal APIs with cert-based auth, and any OCaml application that imports OCaml-TLS and relies on mutual authentication. Indirect dependencies in OCaml projects should be audited using standard dependency scanning tools.

Can an attacker exploit this without holding a valid CA-signed certificate?

No. The attacker must possess a certificate signed by the same Certificate Authority that the target server trusts. This is a meaningful constraint—it requires CA compromise, certificate misissuance, or access to leaked/stolen keys. However, in many enterprise environments, CA scope is broad and multiple applications trust the same CAs, multiplying attack surface.

Will patching OCaml-TLS break my applications?

No breaking changes are expected in the transition from pre-2.1.0 to 2.1.0 in terms of API or core functionality. However, you should test in a staging environment with client certificate authentication enabled to ensure your certificate infrastructure (KeyUsage/ExtendedKeyUsage attributes) is correctly configured before production deployment.

This analysis is based on the official CVE record and public vendor advisory as of June 2026. Specific attack scenarios, exploit code, or working proof-of-concepts are not detailed here. Organizations should verify patch availability and compatibility within their own environment and supply chain. SEC.co makes no warranty regarding the completeness or accuracy of derived insights and recommends consultation with your vendor and internal security teams for deployment decisions. Source: NVD (public-domain), retrieved 2026-07-23. Analysis generated by SEC.co (claude-haiku-4-5).