CVE-2026-23552 - Aceitação de Token Entre Reinos no camel-keycloak

Visão Geral

O KeycloakSecurityPolicy do Apache Camel não valida a declaração iss (emissor) dos tokens JWT em relação ao realm configurado. Isso significa que um token emitido por um realm do Keycloak é silenciosamente aceito por uma política configurada para um realm totalmente diferente, quebrando o isolamento entre tenants.

Versões afetadas: 4.15.0, 4.16.0, 4.17.0

Rastreado em: https://issues.apache.org/jira/browse/CAMEL-22854

Causa raiz

Em KeycloakSecurityHelper.parseAccessToken(), quando nenhuma chave pública é fornecida explicitamente (que é a configuração padrão), o token é apenas decodificado do Base64 -- nunca é verificado:

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

Como o caminho de código padrão atinge o ramo else, três coisas não são verificadas:

1. A assinatura do token nunca é verificada
2. A declaração iss nunca é comparada com a esperada {serverUrl}/realms/{realm}
3. Nenhuma chave pública JWKS é buscada no Keycloak

A verificação de papel (role) ainda passa porque ela apenas analisa os nomes de papéis dentro do payload do token. Se o nome do papel (tenant-user) coincidir entre os realms -- o que é comum em configurações multi-tenant -- a solicitação passa.

Impacto

Em uma aplicação multi-tenant onde cada tenant mapeia para um realm separado no Keycloak, um usuário do tenant A pode acessar rotas protegidas para o tenant B. Concretamente:

• Acesso a dados entre tenants em aplicações SaaS multi-tenant
• Escalonamento de privilégios quando realms diferentes têm configurações de papéis diferentes
• Desvio completo do isolamento de segurança baseado em realms

Reprodução

Este projeto demonstra a vulnerabilidade usando Apache Camel 4.17.0 e uma instância local do Keycloak.

Pré-requisitos

• Java 17+
• Maven 3.9+
• Camel JBang CLI (jbang app install camel@apache/camel)
• Docker ou Podman (usado internamente pelo camel infra)

Configuração

Inicie um Keycloak local:

camel infra run keycloak

Isso inicia o Keycloak em localhost:8080 com credenciais de administrador admin/admin.

Executar

mvn verify

O que acontece

O teste de integração (CrossRealmTokenBypassIT) faz o seguinte:

1. Conecta-se ao Keycloak local e cria dois realms: acme e globex
2. Cria um cliente confidencial em cada realm com concessões de acesso direto habilitadas
3. Cria o papel de realm tenant-user em ambos os realms
4. Cria o usuário alice (senha alice123) no realm acme e atribui a ela o papel tenant-user
5. Configura uma rota Camel (direct:globex-protected) protegida por um KeycloakSecurityPolicy vinculado ao realm globex
6. Obtém um token JWT para alice do realm acme (emissor: http://localhost:8080/realms/acme)
7. Envia esse token para a rota protegida do globex

A requisição é bem-sucedida. O token do acme passa pela política do globex sem nenhum erro.

Resultados esperados dos testes na 4.17.0

Test	Result	Meaning
testAcmeTokenIsObtainable	PASS	Verificação de sanidade -- a obtenção do token funciona
testCrossRealmTokenAccepted	PASS	Confirma que a vulnerabilidade está presente
testCrossRealmTokenShouldBeRejected	FAIL	Documenta o comportamento correto -- no 4.17.0 nenhuma exceção é lançada

Em uma versão corrigida (4.18.0+), o segundo teste falharia e o terceiro passaria.

Limpeza

camel infra stop keycloak

O teste também remove os realms acme e globex no @AfterAll.

Correção

O KeycloakSecurityPolicy deve rejeitar tokens em que a declaração iss não corresponda a {serverUrl}/realms/{realm}. A correção é rastreada em CAMEL-22854 e será lançada com o Camel 4.18.0 (a próxima versão LTS).