What is the CVSS score of CVE-2026-45389?

CVE-2026-45389 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of OCaml-TLS are affected by CVE-2026-45389?

OCaml-TLS server implementations before version 2.1.0 contain a critical authentication bypass in mutual TLS (mTLS) that allows remote attackers to impersonate legitimate clients by presenting…

How to fix or mitigate CVE-2026-45389?

Within 24 hours: Inventory all systems running OCaml-TLS and prioritize those handling mTLS authentication for critical services. Within 7 days: Implement compensating controls (see below) and increase monitoring for authentication anomalies. Within 30 days: Monitor OCaml-TLS project releases; upgrade to version 2.1.0 or later immediately upon availability and validate functionality in staging before production deployment.

OCaml-TLS CVE-2026-45389

EUVD-2026-36765 CRITICAL

Improper Certificate Validation (CWE-295)

2026-06-15 mitre

GHSA-8wf9-g5q8-gg97

Information Disclosure N A

9.1

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

vuln.today AI

9.1 CRITICAL

Network-reachable mTLS endpoint, no prior auth (PR:N) since the bypass is the auth step, low complexity given any chained cert works; high C/I via impersonation, no availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 16, 2026 - 15:30 vuln.today

CVSS changed

Jun 16, 2026 - 15:22 NVD

9.1 (CRITICAL)

CVE Published

Jun 15, 2026 - 00:00 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

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).

AnalysisAI

Authentication bypass in OCaml-TLS server implementations before version 2.1.0 allows remote attackers to impersonate legitimate clients during mutual TLS authentication by presenting certificates whose KeyUsage and ExtendedKeyUsage extensions do not authorize client authentication. The server fails to enforce these X.509 certificate purpose constraints, so any valid certificate chain trusted by the server may be accepted regardless of intended use. EPSS probability is low (0.12%, 2nd percentile) and no public exploit identified at time of analysis, but the CVSS 9.1 reflects the high impact on confidentiality and integrity of mTLS-protected services.

Technical ContextAI

OCaml-TLS is a pure-OCaml implementation of the TLS protocol used by MirageOS unikernels and other OCaml-based servers that perform mutual TLS (mTLS) authentication. X.509 certificates carry KeyUsage (RFC 5280 §4.2.1.3) and ExtendedKeyUsage (§4.2.1.12) extensions that restrict the cryptographic purposes a certificate may be used for - for example, a certificate marked only for serverAuth or codeSigning should not be accepted as a client identity. The vulnerability stems from the server side of OCaml-TLS omitting these purpose checks during the client-certificate verification path, an instance of improper certificate validation (CWE-295 family, though no CWE was assigned in the input). The result is that the chain-of-trust check succeeds without ensuring the leaf certificate was actually issued for client authentication, so any certificate signed by a trusted CA can authenticate as a client.

RemediationAI

Vendor-released patch: OCaml-TLS 2.1.0 - upgrade the ocaml-tls opam dependency to 2.1.0 or later and rebuild and redeploy any unikernels or OCaml services that link it, since OCaml-TLS is statically embedded rather than dynamically loaded. Consult the OSV advisory at https://osv.dev/vulnerability/OSEC-2026-07 and the NVD record at https://nvd.nist.gov/vuln/detail/CVE-2026-45389 for the upstream commit references. Where upgrade cannot be done immediately, compensating controls include narrowing the CA trust store used for client authentication to a dedicated internal CA that only issues client-auth certificates (so no certificate with unintended KeyUsage/EKU is in scope), or terminating mTLS in front of the OCaml-TLS server using a proxy such as nginx or HAProxy that does enforce KeyUsage/EKU; the trade-off is added operational complexity and, for proxy termination, the loss of end-to-end TLS to the OCaml service.