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
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. 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 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.
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.
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.
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. 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 JWT algorithm confusion vulnerability was found in Keycloak's JWT Authorization Grant flow . A flaw in the signature verification logic allows an attacker with valid client credentials to submit a forged assertion using alg=HS256 with the Identity Provider's public key bytes as the HMAC secret, bypassing asymmetric signature verification. This enables the attacker to mint access tokens and impersonate any federated user linked to the affected IdP. The vulnerability requires an IdP configured with jwtAuthorizationGrantEnabled=true, a hardcoded public key (useJwksUrl=false), and no pinned assertion signature algorithm (the default).
Improper access control vulnerability in the JWT authorization grant preview feature of Keycloak. The issue occurs when the --features jwt-authorization-grant option is enabled, and a user account is disabled. Keycloak fails to validate the user’s disabled status during JWT authorization grant processing. By presenting a valid assertion token from an external identity provider, an attacker can obtain a JWT for a disabled user and use it to access protected endpoints. This can be exploited remotely with low privileges and no user interaction, resulting in unauthorized access to sensitive resources.
A vulnerability was identified in Keycloak where the SAML Identity Provider IdP metadata parser incorrectly configures signature validation. When a metadata document is imported that sets WantAuthnRequestsSigned to false and includes a KeyDescriptor without an explicit use attribute, the parser stores the certificate but fails to enable the validateSignature setting. As a result, the broker endpoint /realms/realm/broker/alias/endpoint does not verify the cryptographic signature of incoming SAML responses. An unauthenticated remote attacker can exploit this by capturing a valid RelayState and SAML request ID through a standard login flow and then submitting a forged, unsigned SAML response. By providing the external SAML NameID of a target user, the attacker can successfully authenticate as that user. Successful exploitation allows an attacker to: Bypass authentication mechanisms.
Impersonate any user who has a federated identity link.
Access and modify data belonging to the compromised user account.
A flaw was found in Keycloak where the default Dynamic Client Registration (DCR) policy permits the use of User Property mappers without validating the target claim path. While the policy checks the mapper provider type, it does not restrict where the mapper can write data within the resulting token. An attacker with a standard user account and a limited Initial Access Token (IAT) can register a new client and configure User Property mappers (such as firstName or lastName) to target the resourceaccess.realm-management.roles claim path. By setting their user profile properties to administrative role names (e.g., manage-clients, realm-admin), the attacker can produce a forged access token containing these roles. Although recent mitigations (CVE-2026-4629) protect the Admin REST API from such forged tokens, the Client Registration API remains vulnerable because it reads the resourceaccess claim directly during authorization. An attacker can use this bypass to perform unauthorized DCR operations, including reading confidential client secrets, modifying redirect URIs, and impersonating service accounts to achieve full realm compromise.
A flaw was found in Keycloak, specifically in the organization selection login page. A remote attacker with manage-realm or manage-organizations administrative privileges can exploit a Stored Cross-Site Scripting (XSS) vulnerability. This flaw occurs because the organization.alias is placed into an inline JavaScript onclick handler, allowing a crafted JavaScript payload to execute in a user's browser when they view the login page. Successful exploitation enables arbitrary JavaScript execution, potentially leading to session theft, unauthorized account actions, or further attacks against users of the affected realm.