CVE-2026-23552 - Acceptation de tokens inter-realms dans camel-keycloak

Aperçu

Le KeycloakSecurityPolicy d'Apache Camel ne valide pas la revendication iss (émetteur) des tokens JWT par rapport au realm configuré. Cela signifie qu'un token émis par un realm Keycloak est silencieusement accepté par une politique configurée pour un realm complètement différent, brisant l'isolation des locataires.

Versions affectées : 4.15.0, 4.16.0, 4.17.0

Suivi sur : https://issues.apache.org/jira/browse/CAMEL-22854

Cause racine

Dans KeycloakSecurityHelper.parseAccessToken(), lorsqu'aucune clé publique n'est explicitement fournie (ce qui est la configuration par défaut), le token est seulement décodé depuis le Base64 -- il n'est jamais vérifié :

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();
    }
}

Comme le chemin de code par défaut emprunte la branche else, trois choses ne sont pas vérifiées :

1. La signature du token n'est jamais vérifiée
2. La revendication iss n'est jamais comparée à l'attendu {serverUrl}/realms/{realm}
3. Aucune clé publique JWKS n'est récupérée depuis Keycloak

La vérification du rôle réussit toujours car elle ne regarde que les noms de rôles dans le payload du token. Si le nom du rôle (tenant-user) correspond entre les realms -- ce qui est courant dans les configurations multi-locataires -- la requête passe.

Impact

Dans une application multi-locataire où chaque locataire correspond à un realm Keycloak distinct, un utilisateur du locataire A peut accéder à des routes protégées pour le locataire B. Concrètement :

• Accès aux données inter-locataires dans les applications SaaS multi-locataires
• Escalade de privilèges lorsque différents realms ont des configurations de rôles différentes
• Contournement complet de l'isolation de sécurité basée sur les realms

Reproducteur

Ce projet démontre la vulnérabilité en utilisant Apache Camel 4.17.0 et une instance Keycloak locale.

Prérequis

• Java 17+
• Maven 3.9+
• CLI Camel JBang (jbang app install camel@apache/camel)
• Docker ou Podman (utilisé par camel infra en coulisses)

Configuration

Démarrer un Keycloak local :

camel infra run keycloak

Cela démarre Keycloak sur localhost:8080 avec les identifiants admin admin/admin.

Exécution

mvn verify

Ce qui se passe

Le test d'intégration (CrossRealmTokenBypassIT) effectue ce qui suit :

1. Se connecte au Keycloak local et crée deux realms : acme et globex
2. Crée un client confidentiel dans chaque realm avec les grants d'accès direct activés
3. Crée le rôle de realm tenant-user dans les deux realms
4. Crée l'utilisateur alice (mot de passe alice123) dans le realm acme et lui attribue le rôle tenant-user
5. Configure une route Camel (direct:globex-protected) protégée par un KeycloakSecurityPolicy lié au realm globex
6. Obtient un token JWT pour alice depuis le realm acme (émetteur : http://localhost:8080/realms/acme)

La requête réussit. Le token acme passe la politique globex sans erreur.

Résultats de test attendus sur 4.17.0

Sur une version patchée (4.18.0+), le deuxième test échouerait et le troisième réussirait.

Nettoyage

camel infra stop keycloak

Le test supprime également les realms acme et globex dans @AfterAll.

Correctif

Le KeycloakSecurityPolicy devrait rejeter les tokens dont la revendication iss ne correspond pas à {serverUrl}/realms/{realm}. Le correctif est suivi dans CAMEL-22854 et sera livré avec Camel 4.18.0 (la prochaine version LTS).