Executive Summary

[{'type': 'paragraph', 'content': 'This vulnerability exists in Apache Camel\'s Camel-Keycloak component, specifically in the KeycloakSecurityPolicy. The issue is that the policy does not validate the "iss" (issuer) claim of JWT tokens against the configured Keycloak realm. As a result, a token issued by one Keycloak realm can be accepted by a policy configured for a different realm.'}, {'type': 'paragraph', 'content': 'This breaks tenant isolation, meaning that tokens from one tenant (realm) can be used to access resources or services intended for another tenant, potentially allowing unauthorized access.'}] [1, 2]

Useful 0 Not Useful 0

Impact Analysis

The vulnerability can lead to cross-tenant data access, where a user from one realm can access resources or data belonging to another realm.

It can also cause privilege escalation because role checks only verify role names inside the token payload, and if role names are consistent across realms, unauthorized users can gain access to roles and permissions they should not have.

Overall, this results in a complete bypass of realm-based security isolation, compromising the security of multi-tenant applications.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by testing whether JWT tokens issued by one Keycloak realm are accepted by a system or policy configured for a different realm, indicating a cross-realm token acceptance bypass.'}, {'type': 'paragraph', 'content': 'A practical approach is to create multiple Keycloak realms with identical role names, obtain a JWT token from one realm, and attempt to access resources protected by the KeycloakSecurityPolicy configured for another realm. If access is granted, the vulnerability is present.'}, {'type': 'paragraph', 'content': 'Specifically, you can use tools like curl or HTTP clients to send requests with JWT tokens from one realm to endpoints protected by the vulnerable Apache Camel KeycloakSecurityPolicy and observe if unauthorized access is possible.'}, {'type': 'list_item', 'content': 'Set up two Keycloak realms (e.g., "acme" and "globex") with the same role names.'}, {'type': 'list_item', 'content': 'Obtain a JWT token for a user in the first realm (e.g., using curl or Keycloak CLI).'}, {'type': 'list_item', 'content': 'Send a request to the protected service configured for the second realm, including the JWT token in the Authorization header.'}, {'type': 'list_item', 'content': 'Check if the request is authorized despite the token being from a different realm.'}, {'type': 'paragraph', 'content': 'No specific commands are provided in the resources, but the described method involves using standard HTTP requests with JWT tokens and verifying acceptance across realms.'}] [2]

Useful 0 Not Useful 0

Mitigation Strategies

[{'type': 'paragraph', 'content': 'The immediate and recommended mitigation step is to upgrade Apache Camel to version 4.18.0 or later, where this vulnerability is fixed.'}, {'type': 'paragraph', 'content': 'Version 4.18.0 enforces validation of the issuer ("iss") claim in JWT tokens against the configured Keycloak realm, ensuring tokens from other realms are rejected and tenant isolation is preserved.'}, {'type': 'paragraph', 'content': 'Until the upgrade can be applied, consider reviewing and restricting access controls and monitoring for suspicious cross-realm token acceptance, although no specific workaround is detailed.'}] [1, 2]

Useful 0 Not Useful 0