Ben Smyth

**Name of the Vulnerable Software and Affected Versions** OCaml-TLS versions prior to 2.1.0 **Description** The client implementation in OCaml-TLS fails to properly validate the KeyUsage and ExtendedKeyUsage (EKU) extensions of server certificates during TLS 1.3 handshakes. Specifically, the `answer certificate` function in `handshake client13.ml` is not linked to the `validate keyusage()` function, which is responsible for checking for `Server auth` (OID 1.3.6.1.5.5.7.3.1). This allows an attacker possessing a certificate issued for purposes other than server authentication—such as `clientAuth`, `codeSigning`, or `emailProtection`—to impersonate a server, provided the certificate is issued by a trusted CA and the Subject Alternative Name (SAN) matches the target hostname. **Recommendations** Update OCaml-TLS to version 2.1.0.

**Name of the Vulnerable Software and Affected Versions** OCaml-TLS versions prior to 2.1.0 **Description** The server implementation fails to properly validate the `KeyUsage` and `ExtendedKeyUsage` extensions of certificates provided by clients during mutual TLS (mTLS) authentication. This allows an attacker to impersonate a client using a certificate that was only intended for server authentication (containing `id-kp-serverAuth`). Specifically, the library does not verify if the certificate includes `digitalSignature` in its `keyUsage` or `clientAuth` in its `ExtendedKeyUsage`. Technical details indicate that the issue occurs within the `validateCerts()` function in `handshake server.ml` and the `answerClientCertificate()` function in `handshake server13.ml`, where the `validateChain` process completes without checking these specific constraints. This can lead to unauthorized access if the server trusts a Certificate Authority (CA) that issues server-only certificates, such as a corporate internal CA or a public PKI trust store. **Recommendations** Update to version 2.1.0. As a temporary workaround, restrict the trust store to only include CAs that strictly separate client and server certificates, or implement post-validation gating based on Common Name (CN) or Subject Alternative Name (SAN) to verify the identity of the authenticated client.

Name of the Vulnerable Software and Affected Versions Botan versions prior to 3.11.1 Description The TLS 1.3 implementation in Botan allowed processing of ApplicationData records before the Finished message was received. This could allow a client to bypass server-enforced client authentication via certificates by omitting the Certificate, CertificateVerify, and Finished messages and instead sending application data records. Recommendations Update to version 3.11.1 or later.

**Name of the Vulnerable Software and Affected Versions** Node.js (affected versions not specified) **Description** The generateKeys() API function returned from crypto.createDiffieHellman() only generates missing (or outdated) keys, that is, it only generates a private key if none has been set yet, but the function is also needed to compute the corresponding public key after calling setPrivateKey(). However, the documentation says this API call: "Generates private and public Diffie-Hellman key values". The documented behavior is very different from the actual behavior, and this difference could easily lead to security issues in applications that use these APIs as the DiffieHellman may be used as the basis for application-level security, implications are consequently broad. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Oracle Java SE versions 8u361, 8u361-perf, 11.0.18, 17.0.6, 20 Oracle GraalVM Enterprise Edition versions 20.3.9, 21.3.5, 22.3.1 **Description** The vulnerability is related to the JSSE component of Oracle Java SE and Oracle GraalVM Enterprise Edition, allowing an unauthenticated attacker with network access via TLS to compromise the system. Successful attacks can result in unauthorized creation, deletion, or modification of access to critical data. This issue applies to Java deployments that load and run untrusted code and rely on the Java sandbox for security. It can also be exploited through APIs in the specified component. **Recommendations** For Oracle Java SE versions 8u361, 8u361-perf, 11.0.18, 17.0.6, 20: Update to a fixed version to resolve the issue. For Oracle GraalVM Enterprise Edition versions 20.3.9, 21.3.5, 22.3.1: Update to a fixed version to resolve the issue. As a temporary workaround, consider restricting access to the JSSE component until a patch is available. Avoid using APIs in the specified component, e.g., through a web service, until the issue is resolved.