Overview 15 matches · 2 protected · 1 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
2
13.3%
Rule in development
0
0.0%
Mitigation candidate
1
6.7%
No exploit published
12
80.0%
blocked by ARMR today
2
13.3%
partly blocked
0
0.0%
not blocked
13
86.7%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
1
6.7%
Working exploit published
0
0.0%
Proof of concept only
1
6.7%
Forecast only
0
0.0%
No public exploit
13
86.7%
split by
peak 8 / year
20191
No exploit published1
Critical1
not blocked1
No public exploit1
20201
No exploit published1
Critical1
not blocked1
No public exploit1
20211
No exploit published1
Critical1
not blocked1
No public exploit1
20221
No exploit published1
Critical1
not blocked1
No public exploit1
20233
Protected by Waratek2
No exploit published1
Critical3
blocked by ARMR today2
not blocked1
No public exploit3
20240
20250
20268
Mitigation candidate1
No exploit published7
Critical8
not blocked8
Exploited1
Proof of concept only1
No public exploit6
20192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-120984 | Critical | 2026-11-07 | No exploit published | No public exploit | A flaw was found in the Keycloak server's client management component. When a client is created or imported with authorization services enabled, the system fails to properly clear an internal session attribute used during the setup process. This allows an authenticated attacker with client management permissions to bypass security controls and upload a malicious JavaScript policy, which is then executed on the server when an authorization request is made. Successful exploitation could allow the attacker to run arbitrary code on the server, potentially compromising the entire system. |
| CVE-2026-117691 | Critical | 2026-11-05 | No exploit published | No public exploit | A flaw was found in the SAML HTTP-Redirect binding implementation of Keycloak. The issue occurs because the server processes percent-encoded parameter names (like %53AMLResponse) while the signature verification logic only checks literal parameter names. An attacker can use this discrepancy to provide a crafted, unsigned SAML message that the server processes instead of a legitimately signed one, leading to full account takeover of federated users. |
| CVE-2026-18963 | Critical | 2026-08-18 | Mitigation candidate | Exploited | A flaw was found in the reset-credentials flow of the keycloak-services component, which is the core engine for identity and access management in Red Hat Build of Keycloak. The issue allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link. This can result in the attacker gaining full control over target user accounts by directly setting new credentials. |
| CVE-2026-16443 | Critical | 2026-08-05 | No exploit published | No public exploit | A flaw was found in the SAML metadata import functionality of the keycloak-services component, which is the core engine for identity brokering in Red Hat Build of Keycloak. When importing identity provider metadata that lacks specific usage attributes for keys, the system incorrectly disables signature validation for SAML responses even if a signing certificate is provided. This issue allows an unauthenticated attacker to forge a SAML response and gain unauthorized access to a user account by knowing their external identifier. |
| CVE-2026-16442 | Critical | 2026-08-05 | No exploit published | No public exploit | A flaw was found in the SAML broker component of Keycloak, which is used to manage identity federation and user authentication. The issue occurs because the IdP-initiated Single Sign-On endpoint fails to check if a provider is restricted to account linking only. This allows an attacker with control over a linked upstream identity to bypass login restrictions and gain full access to a local user account. |
| CVE-2026-53913 | Critical | 2026-07-06 | No exploit published | No public exploit | Improper Authentication, Missing Authentication for Critical Function, Not Failing Securely ('Failing Open') vulnerability in Apache Camel Keycloak Component. The KeycloakSecurityPolicy of camel-keycloak guards a route by running KeycloakSecurityProcessor.beforeProcess(), which performs three checks in sequence: it rejects a request that carries no access token, then - only if requiredRoles is non-empty - validates the roles, and - only if requiredPermissions is non-empty - validates the permissions. The actual cryptographic verification of the bearer access token (signature, issuer and expiry for a local JWT, or active-state and issuer for token introspection) is performed exclusively inside those role and permission checks. KeycloakSecurityPolicy defaults requiredRoles and requiredPermissions to empty - which is the documented 'Basic Setup' - so on a route configured that way the role and permission checks are skipped and the access token is therefore never verified. The token-presence check still rejects a missing token, but an invalid token is accepted: any non-null value in the Authorization: Bearer header - including an arbitrary string or a forged, unsigned JWT - passes the policy and the request reaches the protected route, with no signature, issuer or expiry check and no request to Keycloak. The token is read from the inbound request header because allowTokenFromHeader defaults to true. Because the normal reason to place a route behind this policy is that the route performs server-side work, the bypass results in unauthenticated access to that work; where the protected route forwards to a code-execution-capable producer, it can result in unauthenticated remote code execution. This defect is independent of CVE-2026-23552: that issue concerned the issuer claim and was fixed by adding a check inside the verification routine, but here the verification routine is not reached at all in the default configuration, so the defect remains. This issue affects Apache Camel: from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, configure a non-empty requiredRoles or requiredPermissions on every KeycloakSecurityPolicy so that the token-verification path is exercised, set allowTokenFromHeader to false where the token is not expected from the request header, or perform token verification at the framework layer ahead of the policy. |
| CVE-2026-46455 | Critical | 2026-07-06 | No exploit published | No public exploit | Insufficient Session Expiration vulnerability in Apache Camel Keycloak Component. The camel-keycloak security helper KeycloakSecurityHelper.parseAndVerifyAccessToken builds a Keycloak TokenVerifier using withChecks(...) with only the subject-exists check and the realm-URL (issuer) check. Keycloak's TokenVerifier.withChecks(...) appends to an initially empty check list - the upstream default checks are installed only when withDefaultChecks() is called - so the built-in IS_ACTIVE predicate, which validates the token's exp (expiration) and nbf (not-before) claims, is never applied. As a result the helper verifies the token signature, subject and issuer but does not enforce the token's validity window: an access token that is expired, or not yet valid, is accepted as valid. Routes that rely on this helper to authenticate inbound requests therefore accept access tokens that are outside their intended lifetime. This issue affects Apache Camel: from 4.18.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes KeycloakSecurityHelper.parseAndVerifyAccessToken include the TokenVerifier.IS_ACTIVE check so that expired or not-yet-valid access tokens are rejected, aligning the helper with Keycloak's default check set. For deployments that cannot upgrade immediately, enforce token expiration outside the helper - for example validate the access token's exp/nbf claims in the route before trusting it, keep Keycloak access-token lifetimes short, and ensure any upstream gateway or resource server also validates the token validity window. |
| CVE-2026-23552 | Critical | 2026-02-23 | No exploit published | Proof of concept only | Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicy Apache Camel Keycloak component. The Camel-Keycloak KeycloakSecurityPolicy does not validate the iss (issuer) claim of JWT tokens against the configured realm. A token issued by one Keycloak realm is silently accepted by a policy configured for a completely different realm, breaking tenant isolation. This issue affects Apache Camel: from 4.15.0 before 4.18.0. Users are recommended to upgrade to version 4.18.0, which fixes the issue. |
| CVE-2022-4361 | Critical | 2023-07-07 | Protected by Waratek | No public exploit | Keycloak, an open-source identity and access management solution, has a cross-site scripting (XSS) vulnerability in the SAML or OIDC providers. The vulnerability can allow an attacker to execute malicious scripts by setting the AssertionConsumerServiceURL value or the redirect_uri. |
| CVE-2023-24456 | Critical | 2023-01-26 | No exploit published | No public exploit | Jenkins Keycloak Authentication Plugin 2.3.0 and earlier does not invalidate the previous session on login. |
| CVE-2022-3782 | Critical | 2023-01-13 | Protected by Waratek | No public exploit | keycloak: path traversal via double URL encoding. A flaw was found in Keycloak, where it does not properly validate URLs included in a redirect. An attacker can use this flaw to construct a malicious request to bypass validation and access other URLs and potentially sensitive information within the domain or possibly conduct further attacks. This flaw affects any client that utilizes a wildcard in the Valid Redirect URIs field. |
| CVE-2022-1245 | Critical | 2022-07-08 | No exploit published | No public exploit | A privilege escalation flaw was found in the token exchange feature of keycloak. Missing authorization allows a client application holding a valid access token to exchange tokens for any target client by passing the client_id of the target. This could allow a client to gain unauthorized access to additional services. |
| CVE-2021-20195 | Critical | 2021-05-28 | No exploit published | No public exploit | A flaw was found in keycloak in versions before 13.0.0. A Self Stored XSS attack vector escalating to a complete account takeover is possible due to user-supplied data fields not being properly encoded and Javascript code being used to process the data. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability. |
| CVE-2020-1731 | Critical | 2020-03-02 | No exploit published | No public exploit | A flaw was found in all versions of the Keycloak operator, before version 8.0.2,(community only) where the operator generates a random admin password when installing Keycloak, however the password remains the same when deployed to the same OpenShift namespace. |
| CVE-2019-14910 | Critical | 2019-12-05 | No exploit published | No public exploit | A vulnerability was found in keycloak 7.x, when keycloak is configured with LDAP user federation and StartTLS is used instead of SSL/TLS from the LDAP server (ldaps), in this case user authentication succeeds even if invalid password has entered. |