See how keycloak compares to other vendors in security performance
It was found that the Keycloak Node.js adapter 2.5 - 3.0 did not handle invalid tokens correctly. An attacker could use this flaw to bypass authentication and gain access to restricted information, or to possibly conduct further attacks.
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.
A flaw was found in Keycloak. A vulnerability exists in the jwt-authorization-grant flow where the server fails to verify if an Identity Provider (IdP) is enabled before issuing tokens. The issuer lookup mechanism (lookupIdentityProviderFromIssuer) retrieves the IdP configuration but does not filter for isEnabled=false. If an administrator disables an IdP (e.g., due to a compromise or offboarding), an entity possessing that IdP's signing key can still generate valid JWT assertions that Keycloak accepts, resulting in the issuance of valid access tokens.
A flaw was found in Keycloak. An authenticated user with low privileges can exploit this vulnerability by sending an oversized subjecttoken JSON Web Token (JWT) to the TokenEndpoint. When the token exceeds a 4000-character limit, it is silently dropped, causing the system to fall back to client credentials. This allows the user to gain the permissions of the client's service account, leading to privilege escalation.
https://issues.jboss.org/browse/KEYCLOAK-5299
It was discovered that the org.keycloak.services.resources.SocialResource.callback(String) method implementation lacked CSRF protection. A remote attacker could use this flaw to gain access to a KeyCloak managed accounts or perform other attacks.
A flaw was found in Keycloak. By setting a verification policy to 'ALL', the trust store certificate verification is skipped, which is unintended.
A flaw was found in Keycloak. An authenticated user with the umaprotection role can bypass User-Managed Access (UMA) policy validation. This allows the attacker to include resource identifiers owned by other users in a policy creation request, even if the URL path specifies an attacker-owned resource. Consequently, the attacker gains unauthorized permissions to victim-owned resources, enabling them to obtain a Requesting Party Token (RPT) and access sensitive information or perform unauthorized actions.
A flaw was found in Keycloak. The cross-session verification proof is keyed only by (local userId, idpAlias) and is not bound to the upstream identity that was actually verified, so a second upstream account on the same IdP can consume it and get linked to the victim's local account.
A flaw was found in Keycloak Policy Enforcer. This vulnerability allows any authenticated user to bypass all authorization policies, including role, scope, and User-Managed Access (UMA) permission checks. By including the configured access-denied page path within a request URL, either as a path segment or a query parameter, an attacker can gain unauthorized access to protected resources.
A flaw was found in Keycloak. This JWT algorithm confusion vulnerability in the JWT Authorization Grant flow allows an attacker with valid client credentials to bypass signature verification. By forging an assertion, the attacker can create unauthorized access tokens. This enables the attacker to impersonate any federated user linked to the affected Identity Provider, leading to unauthorized access and potential privilege escalation.
A flaw was found in Keycloak. When the JSON Web Token (JWT) authorization grant preview feature is enabled and a user account is disabled, Keycloak fails to validate the user’s disabled status during JWT authorization grant processing. A remote attacker with low privileges can exploit this improper access control vulnerability by presenting a valid assertion token from an external identity provider to obtain a JWT for a disabled user. This allows unauthorized access to sensitive resources.
A Missing Authorization vulnerability was identified in Keycloak Google Identity Provider implementation. The flaw exists in the external access-token exchange code path, which is used when the Token Exchange V1 feature is enabled. While the standard Google ID-token login flow correctly validates the hd hosted domain claim against the configured hostedDomain setting, the access-token exchange flow skips this validation. When an external access token is provided, Keycloak retrieves the user profile from the Google user-info endpoint but fails to verify that the domain associated with the user matches the restricted domain configured in the Identity Provider settings. An attacker with a valid Google access token for any domain can exploit this flaw if they have access to a confidential client authorized to perform token exchange. Successful exploitation allows the attacker to bypass domain restrictions, obtain a Keycloak access token, and potentially create or link a brokered identity that should have been restricted.
A flaw was found in Keycloak's Authorization Services. The component responsible for matching request paths to security policies (PathMatcher) does not properly normalize URIs before comparison. By adding extra characters like a trailing slash or matrix parameters to a URL, an attacker can trick the system into applying a less restrictive security policy than intended. This allows an authenticated user to access administrative or restricted areas they should not have permission to see.
A flaw was found in the SAML broker component of Keycloak, an identity and access management solution. When configured as a SAML broker using the IdP-Initiated flow, Keycloak fails to enforce the OneTimeUse condition in SAML assertions. This allows an attacker who captures a valid, unused assertion to replay it multiple times. Successful exploitation could allow an attacker to hijack a user's session and gain unauthorized access to the system as that user.
A flaw was found in Keycloak. Keycloak's Security Assertion Markup Language (SAML) broker endpoint does not properly validate encrypted assertions when the overall SAML response is not signed. An attacker with a valid signed SAML assertion can exploit this by crafting a malicious SAML response. This allows the attacker to inject an encrypted assertion for an arbitrary principal, leading to unauthorized access and potential information disclosure.
A flaw was found in Keycloak. A missing authorization check in the GroupResource.addChild() endpoint within the Admin REST API allows an authenticated user with limited administrative privileges to reparent any existing group. When Fine-Grained Admin Permissions v2 (FGAPv2) is enabled, an attacker with management rights over a single low-privilege group can reparent a highly privileged group (such as one possessing the realm-admin role) under their managed group.
Because group permissions follow a hierarchical structure, this action unauthorizedly grants the attacker management and password-reset capabilities over the members of the targeted privileged group. An attacker can exploit this to reset an administrator's password, compromise the account, and achieve a full realm takeover, leading to a complete compromise of confidentiality, integrity, and availability.
A flaw was found in Keycloak. An unauthenticated attacker can exploit this vulnerability by sending a specially crafted POST request with an excessively long scope parameter to the OpenID Connect (OIDC) token endpoint. This leads to high resource consumption and prolonged processing times, ultimately resulting in a Denial of Service (DoS) for the Keycloak server.
A flaw was found in Keycloak. A remote, unauthenticated attacker can send a specially crafted XML input to the Security Assertion Markup Language (SAML) endpoint. This malicious input can cause high CPU usage and worker thread starvation, leading to a Denial of Service (DoS) where the server becomes unavailable.
A flaw was found in Keycloak. When a JSON Web Encryption (JWE) encrypted request object is submitted, Keycloak may incorrectly process unsigned claims if the decrypted content is raw JSON, bypassing the configured signature policy. This allows a remote attacker to submit unauthorized claims, leading to a compromise of data integrity within the OpenID Connect (OIDC) authorization flow. While a redirect URI allowlist acts as a compensating control, this vulnerability violates OIDC Core and Financial-grade API (FAPI) signing requirements.
It was discovered that by requesting a large enough image size for a generated QR code, a remote attacker could cause uncontrolled resource consumption leading to denial of service for legitimate users.
Upstream Issue:
https://issues.jboss.org/browse/KEYCLOAK-699
It was found that the cookie used for CSRF prevention in Keycloak was not unique to each session. An attacker could use this flaw to gain access to an authenticated user session, leading to possible information disclosure or further attacks.
A flaw was found in Keycloak. This issue allows an attacker, who controls another path on the same web server, to bypass the allowed path in redirect Uniform Resource Identifiers (URIs) that use a wildcard. A successful attack may lead to the theft of an access token, resulting in information disclosure.
Description A flaw was found in Keycloak's Fine-Grained Admin Permissions (FGAPv2) feature. An administrator with limited client management permissions can exploit this vulnerability to assign any realm role, including highly privileged roles, to a client's scope mapping. This bypasses intended security controls, allowing the injected role to be projected into a user's authentication token when they access the modified client. This could lead to unauthorized privilege escalation within the Keycloak realm.
A flaw was found in Keycloak. A remote attacker with administrative privileges, specifically those with manage-client permission or access to client registration endpoints, could bypass client Uniform Resource Identifier (URI) validation. This is achieved by registering a malicious client with a specially crafted redirect URI using a case-insensitive javascript: or data: scheme. This Cross-Site Scripting (XSS) vulnerability allows for arbitrary code execution in the Keycloak origin when a victim clicks the crafted link, such as in the logout flow or the Admin Console.
A Broken Access Control vulnerability was identified in Keycloaks Fine-Grained Admin Permissions V2 (FGAP V2) implementation. The flaw exists in the POST /admin/realms/{realm}/users endpoint, where the server fails to validate group membership permissions within the user creation payload. While Keycloak correctly enforces manage-membership scopes for existing users, it misses this check during the initial user creation process. A sub-administrator with user create scope but restricted group manage-membership scope can successfully assign a new user to unauthorized groups by including them in the creation request. Concrete impact: An attacker with sub-admin privileges can elevate the permissions of new users, grant them access to restricted data by placing them in sensitive groups, and bypass the security boundaries established by FGAP V2.
A flaw was found in Keycloak. A low-privilege user, with knowledge of user credentials and client ID, can bypass a security control intended to disable the implicit flow in OpenID Connect (OIDC) clients. By manipulating client data during a session restart, an attacker can obtain an access token that should not be available. This vulnerability can also lead to the exposure of these access tokens in server logs, proxy logs, and HTTP Referrer headers, resulting in sensitive information disclosure.
A flaw was found in Keycloak. A remote, unauthenticated attacker can send a specially crafted XML input to the Security Assertion Markup Language (SAML) endpoint. This malicious input can cause high CPU usage and worker thread starvation, leading to a Denial of Service (DoS) where the server becomes unavailable.
Summary
Under FGAPv2, the ScopeMappedResource and ScopeMappedClientResource write endpoints (add and delete scope mappings) do not call requireMapClientScope per role. An admin holding only fine-grained manage on a single client can attach any realm role — including realm-admin — to that client's scope mapping, bypassing the MAPROLECLIENTSCOPE permission boundary. When a privileged user subsequently authenticates through the modified client, the injected role is projected into the issued token.
Requirements to exploit
FGAPv2 enabled on the realm (adminPermissionsEnabled=true)
Attacker holds fine-grained manage permission on at least one client
A user holding the targeted role (e.g. realm-admin) must authenticate through the modified client
Component affected: org.keycloak.services.resources.admin
Version affected: All versions with FGAPv2 support
Patch available: no
File issue trackers? Yes
CVSS: CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N (7.3 High)
Embargo: no
Acknowledgement:
Andrej Tomci
Github - @andrejtomci
Steps to reproduce
1. Enable FGAPv2 on the realm (adminPermissionsEnabled=true) 2. Create a delegated admin with fine-grained manage on a single client — no global manage-clients, no MAPROLECLIENTSCOPE on any privileged role 3. As the delegated admin, call POST /admin/realms/{r}/clients/{uuid}/scope-mappings/realm with realm-admin in the roles body — the request succeeds despite no MAPROLECLIENTSCOPE permission 4. Optionally flip fullScopeAllowed=true on the client via PUT /admin/realms/{r}/clients/{uuid} 5. Authenticate as a user holding realm-admin through the modified client 6. Inspect the issued token — realm-admin is projected into the token via the injected scope mapping
Privilege escalation in Keycloak via POST /admin/realms/{realm}/partialImport. The endpoint bypasses Fine-Grained Admin Permissions (FGAP) -- it only checks requireManageRealm() but not per-resource-type permissions. A limited admin with only manage-realm can escalate to full realm admin by importing users with realm-admin role mappings. Verified on Keycloak 26.6.1.
Related: GitHub issue #9387 describes this as hardening, but it is an exploitable privilege escalation.