CVE-2026-23552 - Akzeptanz realmübergreifender Token in camel-keycloak

Überblick

Die KeycloakSecurityPolicy von Apache Camel validiert den iss-Anspruch (Issuer) von JWT-Tokens nicht gegen die konfigurierte Realm. Das bedeutet, dass ein Token, das von einer Keycloak-Realm ausgestellt wurde, stillschweigend von einer Richtlinie akzeptiert wird, die für eine völlig andere Realm konfiguriert ist, wodurch die Mandantenisolation aufgehoben wird.

Betroffene Versionen: 4.15.0, 4.16.0, 4.17.0

Verfolgt unter: https://issues.apache.org/jira/browse/CAMEL-22854

Ursache

In KeycloakSecurityHelper.parseAccessToken() wird das Token, wenn kein öffentlicher Schlüssel explizit angegeben wird (was der Standardkonfiguration entspricht), nur aus Base64 dekodiert -- es wird niemals verifiziert:

public static AccessToken parseAccessToken(String tokenString, PublicKey publicKey)
        throws VerificationException {
    if (publicKey != null) {
        return TokenVerifier.create(tokenString, AccessToken.class)
                .publicKey(publicKey)
                .verify()
                .getToken();
    } else {
        // no signature verification, no issuer check
        return TokenVerifier.create(tokenString, AccessToken.class).getToken();
    }
}

Da der Standardcodepfad den else-Zweig erreicht, bleiben drei Dinge ungeprüft:

1. Die Tokensignatur wird nie verifiziert
2. Der iss-Anspruch wird nie mit dem erwarteten {serverUrl}/realms/{realm} verglichen
3. Es wird kein öffentlicher JWKS-Schlüssel von Keycloak abgerufen

Die Rollenprüfung besteht trotzdem, weil sie nur die Rollennamen innerhalb der Token-Nutzlast betrachtet. Wenn der Rollenname (tenant-user) zufällig über Realms hinweg übereinstimmt -- was in Multi-Tenant-Setups häufig vorkommt -- wird die Anfrage durchgelassen.

Auswirkungen

In einer Multi-Tenant-Anwendung, bei der jeder Mandant einer separaten Keycloak-Realm zugeordnet ist, kann ein Benutzer von Mandant A auf Routen zugreifen, die für Mandant B geschützt sind. Konkret:

• Mandantenübergreifender Datenzugriff in Multi-Tenant-SaaS-Anwendungen
• Privilegienerweiterung, wenn verschiedene Realms unterschiedliche Rollenkonfigurationen haben
• Vollständige Umgehung der realm-basierten Sicherheitsisolation

Reproduktion

Dieses Projekt demonstriert die Schwachstelle mit Apache Camel 4.17.0 und einer lokalen Keycloak-Instanz.

Voraussetzungen

• Java 17+
• Maven 3.9+
• Camel JBang CLI (jbang app install camel@apache/camel)
• Docker oder Podman (wird von camel infra unter der Haube verwendet)

Einrichtung

Eine lokale Keycloak-Instanz starten:

camel infra run keycloak

Dies startet Keycloak auf localhost:8080 mit den Admin-Zugangsdaten admin/admin.

Ausführen

mvn verify

Was passiert

Der Integrationstest (CrossRealmTokenBypassIT) führt Folgendes aus:

1. Verbindet sich mit der lokalen Keycloak-Instanz und erstellt zwei Realms: acme und globex
2. Erstellt in jeder Realm einen vertraulichen Client mit aktivierten Direct-Access-Grants
3. Erstellt die Realm-Rolle tenant-user in beiden Realms
4. Erstellt Benutzer alice (Passwort alice123) in der acme-Realm und weist ihr die Rolle tenant-user zu
5. Richtet eine Camel-Route (direct:globex-protected) ein, die durch eine an die globex-Realm gebundene KeycloakSecurityPolicy geschützt ist
6. Besorgt ein JWT-Token für alice von der acme-Realm (Issuer: http://localhost:8080/realms/acme)

Die Anfrage ist erfolgreich. Das acme-Token passiert die globex-Richtlinie ohne Fehler.

Erwartete Testergebnisse unter 4.17.0

Bei einer gepatchten Version (4.18.0+) würde der zweite Test fehlschlagen und der dritte bestehen.

Aufräumen

camel infra stop keycloak

Der Test entfernt außerdem die acme- und globex-Realms in @AfterAll.

Fix

Die KeycloakSecurityPolicy sollte Tokens ablehnen, bei denen der iss-Anspruch nicht mit {serverUrl}/realms/{realm} übereinstimmt. Der Fix wird in CAMEL-22854 verfolgt und mit Camel 4.18.0 (dem nächsten LTS-Release) ausgeliefert.