Loading vulnerability…
CVE-2026-23552 is an authentication and authorization bypass vulnerability in the Apache Camel Keycloak component's KeycloakSecurityPolicy. The flaw arises because the policy does not validate the JWT iss (issuer) claim 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. This breaks realm and tenant isolation assumptions in deployments that rely on Keycloak realms as security boundaries. The issue affects Apache Camel versions 4.15.0 through versions before 4.18.0.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Repository purpose: a Maven-based Java integration-test reproducer for CVE-2026-23552 affecting Apache Camel’s `camel-keycloak` (4.15.0–4.17.0). The vulnerability is that `KeycloakSecurityPolicy` accepts JWTs from the wrong Keycloak realm because the default token parsing path does not verify the JWT signature and does not validate the `iss` (issuer) claim against the configured realm. Structure: - `README.md`: Explains the issue, affected versions, root cause (missing verification/issuer check when no public key is configured), impact (cross-tenant access), and how to run the reproducer with a local Keycloak. - `pom.xml`: Pins Camel 4.17.0 and includes `camel-keycloak`, JUnit5, and Keycloak admin client dependencies; uses Maven Failsafe for integration tests. - `src/test/java/.../CrossRealmTokenBypassIT.java`: Main PoC. Connects to Keycloak at `http://localhost:8080` as `admin` in the `master` realm, programmatically creates two realms (`acme`, `globex`), creates clients and a shared role name (`tenant-user`) in both realms, creates user `alice` only in `acme`, obtains an access token from `acme` via the OIDC token endpoint (`/realms/{realm}/protocol/openid-connect/token`) using password grant, then sends that token to a Camel route protected by a `KeycloakSecurityPolicy` configured for `globex`. The test demonstrates that the request succeeds due to cross-realm token acceptance. - `src/test/resources/logback-test.xml`: Logging configuration to aid debugging. Exploit capability (what it demonstrates): an authentication/authorization boundary failure in multi-tenant setups where realms represent tenants. A token minted by one realm can be replayed against routes protected for another realm if role names overlap, enabling cross-tenant data access. No RCE; it is an authorization bypass PoC.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
10 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.