https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 11:51:26 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-45389 <p>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).</p> <p>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).</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-45389 https://vulnerability.circl.lu/vuln/ghsa-8wf9-g5q8-gg97 <p>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).</p> <p>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).</p> https://vulnerability.circl.lu/vuln/ghsa-8wf9-g5q8-gg97 https://vulnerability.circl.lu/vuln/osec-2026-07 <p><strong>Affected:</strong> opam: tls</p> <p>The TLS server implementation does not validate the KeyUsage and ExtendedKeyUsage extensions of client certificates when mutually authenticated TLS is requested. This can lead to impersonation with a certificate issued to a server.</p> <p>## Scenario</p> <p>An operations engineer enables mTLS on the admin endpoint of a banking service. The setup is canonical: provide an `authenticator` on the `ocaml-tls` listener. She believes the gate is now set: only certificates issued under the corporate root, intended for client authentication, can authenticate at the admin endpoint.</p> <p>An attacker inside the same corporate trust domain holds the legitimate TLS server cert for some internal HTTPS service they administer. The cert is real, signed by the corporate root, valid, not revoked. Its Extended Key Usage extension lists `id-kp-serverAuth` and nothing else — the cert was issued for serving HTTPS, not for authenticating clients. The X.509 RFC says exactly that distinction: a cert&#39;s role is constrained by its EKU, and a serverAuth-only cert is not authorised to act as a client.</p> <p>The attacker presents that cert to the bank&#39;s `ocaml-tls` mTLS listener. The hook fires, the chain validates against the corporate root. The `ocaml-tls` library&#39;s does neither check that the presented certificate includes `digitalSignature` in its keyUsage, neither looks that `clientAuth` is present in the ExtendedKeyUsage. The handshake completes. The attacker is now authenticated as a client at the bank&#39;s admin endpoint,…</p> <p><strong>Affected:</strong> opam: tls</p> <p>The TLS server implementation does not validate the KeyUsage and ExtendedKeyUsage extensions of client certificates when mutually authenticated TLS is requested. This can lead to impersonation with a certificate issued to a server.</p> <p>## Scenario</p> <p>An operations engineer enables mTLS on the admin endpoint of a banking service. The setup is canonical: provide an `authenticator` on the `ocaml-tls` listener. She believes the gate is now set: only certificates issued under the corporate root, intended for client authentication, can authenticate at the admin endpoint.</p> <p>An attacker inside the same corporate trust domain holds the legitimate TLS server cert for some internal HTTPS service they administer. The cert is real, signed by the corporate root, valid, not revoked. Its Extended Key Usage extension lists `id-kp-serverAuth` and nothing else — the cert was issued for serving HTTPS, not for authenticating clients. The X.509 RFC says exactly that distinction: a cert&#39;s role is constrained by its EKU, and a serverAuth-only cert is not authorised to act as a client.</p> <p>The attacker presents that cert to the bank&#39;s `ocaml-tls` mTLS listener. The hook fires, the chain validates against the corporate root. The `ocaml-tls` library&#39;s does neither check that the presented certificate includes `digitalSignature` in its keyUsage, neither looks that `clientAuth` is present in the ExtendedKeyUsage. The handshake completes. The attacker is now authenticated as a client at the bank&#39;s admin endpoint,…</p> https://vulnerability.circl.lu/vuln/osec-2026-07