<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T11:51:26.166352+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-45389</id>
    <title>fkie_cve-2026-45389</title>
    <updated>2026-09-29T11:51:29.477737+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <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>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-45389"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-8wf9-g5q8-gg97</id>
    <title>GHSA-8wf9-g5q8-gg97</title>
    <updated>2026-09-29T11:51:29.477825+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <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>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-8wf9-g5q8-gg97"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/osec-2026-07</id>
    <title>OSEC-2026-07 — TLS-server does insufficient client certificate checks (missing KeyUsage and ExtendedKeyUsage validation)</title>
    <updated>2026-09-29T11:51:29.477861+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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'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's `ocaml-tls` mTLS listener. The hook fires, the chain validates against the corporate root. The `ocaml-tls` library'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's admin endpoint,…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/osec-2026-07"/>
  </entry>
</feed>
