CVE-2026-23552 - Accettazione di token cross-realm in camel-keycloak

Panoramica

La KeycloakSecurityPolicy di Apache Camel non valida il claim iss (issuer) dei token JWT rispetto al realm configurato. Ciò significa che un token emesso da un realm Keycloak viene silenziosamente accettato da una policy configurata per un realm completamente diverso, rompendo l'isolamento tra tenant.

Versioni interessate: 4.15.0, 4.16.0, 4.17.0

Tracciato su: https://issues.apache.org/jira/browse/CAMEL-22854

Causa principale

In KeycloakSecurityHelper.parseAccessToken(), quando non viene fornita esplicitamente alcuna chiave pubblica (che è la configurazione predefinita), il token viene solo decodificato da Base64 -- non viene mai verificato:

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

Poiché il percorso di codice predefinito raggiunge il ramo else, tre cose restano senza controllo:

1. La firma del token non viene mai verificata
2. Il claim iss non viene mai confrontato con il valore atteso {serverUrl}/realms/{realm}
3. Nessuna chiave pubblica JWKS viene recuperata da Keycloak

Il controllo dei ruoli passa comunque perché guarda solo ai nomi dei ruoli all'interno del payload del token. Se il nome del ruolo (tenant-user) corrisponde tra i diversi realm -- cosa comune in configurazioni multi-tenant -- la richiesta viene accettata.

Impatto

In un'applicazione multi-tenant in cui ogni tenant corrisponde a un realm Keycloak separato, un utente del tenant A può accedere alle route protette per il tenant B. Nello specifico:

• Accesso ai dati cross-tenant in applicazioni SaaS multi-tenant
• Escalation dei privilegi quando realm diversi hanno configurazioni di ruoli differenti
• Bypass completo dell'isolamento di sicurezza basato sul realm

Riproduttore

Questo progetto dimostra la vulnerabilità usando Apache Camel 4.17.0 e un'istanza Keycloak locale.

Prerequisiti

• Java 17+
• Maven 3.9+
• CLI Camel JBang (jbang app install camel@apache/camel)
• Docker o Podman (usati da camel infra internamente)

Configurazione

Avvia un Keycloak locale:

camel infra run keycloak

Questo avvia Keycloak su localhost:8080 con credenziali admin admin/admin.

Esecuzione

mvn verify

Cosa succede

Il test di integrazione (CrossRealmTokenBypassIT) fa quanto segue:

1. Si connette al Keycloak locale e crea due realm: acme e globex
2. Crea un client confidenziale in ciascun realm con i direct access grants abilitati
3. Crea il ruolo di realm tenant-user in entrambi i realm
4. Crea l'utente alice (password alice123) nel realm acme e le assegna il ruolo tenant-user
5. Configura una route Camel (direct:globex-protected) protetta da una KeycloakSecurityPolicy legata al realm globex
6. Ottiene un token JWT per alice dal realm acme (issuer: http://localhost:8080/realms/acme)

La richiesta viene accettata. Il token di acme supera la policy di globex senza alcun errore.

Risultati attesi dei test su 4.17.0

Su una versione corretta (4.18.0+), il secondo test fallirebbe e il terzo passerebbe.

Pulizia

camel infra stop keycloak

Il test rimuove anche i realm acme e globex in @AfterAll.

Fix

La KeycloakSecurityPolicy dovrebbe rifiutare i token in cui il claim iss non corrisponde a {serverUrl}/realms/{realm}. Il fix è tracciato in CAMEL-22854 e sarà incluso in Camel 4.18.0 (la prossima release LTS).