CVE-2026-23552: 
Java vulnerability analysis and mitigation

CVE-2026-23552 is a Cross-Realm Token Acceptance Bypass vulnerability in the camel-keycloak component (KeycloakSecurityPolicy) of Apache Camel. The flaw allows a JWT token issued by one Keycloak realm to be silently accepted by a policy configured for a completely different realm, breaking tenant isolation. It affects Apache Camel versions 4.15.0 through 4.17.x (before 4.18.0) and carries a CVSS v3.1 base score of 9.1 (Critical) (Feedly, Apache Advisory). The vulnerability was discovered and disclosed by Andrea Cosentino on February 18, 2026, via the oss-security mailing list (Openwall).

The root cause is an Origin Validation Error (CWE-346) in KeycloakSecurityHelper.parseAccessToken(). When no explicit public key is provided — the default configuration — the method decodes the JWT from Base64 without performing signature verification, without comparing the iss (issuer) claim to the expected {serverUrl}/realms/{realm} value, and without fetching a JWKS public key from Keycloak (GitHub PoC). Because the downstream role check only inspects role names within the token payload, an attacker holding a valid token from realm A can present it to a route protected by a policy bound to realm B — and succeed if the role name (e.g., tenant-user) exists in both realms, which is common in multi-tenant deployments. The attack is network-based, requires no authentication or user interaction, and has low attack complexity (Feedly). A public proof-of-concept reproducer is available at GitHub PoC.

Successful exploitation breaks tenant isolation in multi-tenant Apache Camel applications, allowing a user authenticated to one Keycloak realm to access routes and resources protected for an entirely different realm without possessing valid credentials for that realm. This results in high confidentiality impact (unauthorized cross-tenant data disclosure) and high integrity impact (unauthorized data modification), with no availability impact (Feedly). In SaaS environments, this can enable cross-tenant data access and privilege escalation when different realms carry different role configurations, potentially compromising the entire security boundary between tenants (GitHub PoC).

1. Reconnaissance: Identify target applications using Apache Camel 4.15.0–4.17.x with the camel-keycloak component and KeycloakSecurityPolicy configured for a specific Keycloak realm (realm B / globex).
2. Obtain a valid token from a different realm: Authenticate to a Keycloak realm the attacker controls or has credentials for (realm A / acme) to obtain a signed JWT token. The token's iss claim will be http://<keycloak-host>/realms/acme.
3. Identify matching role names: Determine the role name required by the target route's KeycloakSecurityPolicy (e.g., tenant-user). Ensure the attacker's token from realm A contains this same role name in its payload.
4. Submit the cross-realm token: Send an HTTP request to the Camel route protected by the globex realm policy, including the acme-issued JWT in the Authorization: Bearer <token> header.
5. Bypass succeeds: Because KeycloakSecurityHelper.parseAccessToken() skips signature verification and iss claim validation in the default (no public key) configuration, the token is accepted and the route is executed with the attacker's identity, granting unauthorized access to realm B's resources (GitHub PoC, Openwall).

• Network: HTTP requests to Camel routes protected by KeycloakSecurityPolicy bearing JWT tokens whose iss claim does not match the configured realm URL (e.g., iss contains /realms/acme on a route configured for /realms/globex).
• Logs: Application logs showing successful authorization on realm-protected Camel routes from tokens with mismatched issuer claims; absence of VerificationException in Camel Keycloak logs where cross-realm access is attempted.
• Logs: Keycloak audit logs showing token issuance for realm A followed immediately by access attempts on services expected to be restricted to realm B users.
• Behavioral: Unexpected cross-tenant data access patterns — users from one organizational tenant accessing data or APIs belonging to another tenant without a corresponding login event in the target realm (GitHub PoC).

The primary remediation is to upgrade Apache Camel to version 4.18.0 or later, which introduces proper iss claim validation in KeycloakSecurityPolicy to reject tokens whose issuer does not match the configured realm (Apache Advisory, Openwall). If immediate patching is not feasible, explicitly configure a public key in KeycloakSecurityPolicy — this forces the code path that performs TokenVerifier signature verification, partially mitigating the bypass (GitHub PoC). Additionally, implement network-level access controls to restrict which clients can reach realm-protected Camel routes, and audit logs for suspicious cross-realm token usage patterns as a detective control (Feedly).

The vulnerability was disclosed by its discoverer, Apache Camel committer Andrea Cosentino, via the oss-security mailing list and accompanied by a detailed GitHub PoC repository (Openwall, GitHub PoC). Security news outlet The Hacker Wire published a dedicated article on the cross-realm bypass (The Hacker Wire), and SecurityOnline.info covered it as part of Apache Camel's critical patch release (SecurityOnline). Community discussion also appeared on Bluesky and Mastodon, and the vulnerability was contextualized alongside other 2026 JWT algorithm confusion CVEs in developer-focused posts on dev.to and Medium (Feedly).