Search
Search Results (7 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-14613 | 1 Redhat | 8 Build Keycloak, Build Of Keycloak, Data Grid and 5 more | 2026-07-29 | 4.3 Medium |
| A vulnerability was discovered in Keycloak's administrative interface that allows certain administrators to see information about groups they shouldn't have access to. When the new Fine-Grained Admin Permissions (FGAP v2) are turned on, an administrator who is allowed to see a specific "role" can also see a list of all groups assigned to that role. The system fails to check if the administrator has permission to see those specific groups. This could allow a restricted administrator to discover "hidden" groups and see their details, such as internal names and custom settings, which might contain sensitive deployment information. | ||||
| CVE-2026-14614 | 1 Redhat | 8 Build Keycloak, Build Of Keycloak, Data Grid and 5 more | 2026-07-29 | 5.4 Medium |
| A flaw was found in the ClientResource component of Keycloak's admin services when Fine-Grained Admin Permissions (FGAP) v2 is enabled. This issue allows a delegated administrator, who should only have limited control over specific clients, to attach or remove hidden client scopes that they are not authorized to see or manage. As a result, an attacker could inject unauthorized data or permissions into the security tokens issued to end-users, potentially tricking other applications into granting higher levels of access than intended. | ||||
| CVE-2026-14781 | 1 Redhat | 8 Build Keycloak, Build Of Keycloak, Data Grid and 5 more | 2026-07-29 | 4.8 Medium |
| A flaw exists in the org.keycloak.broker.oidc package where the OIDC broker incorrectly synchronizes the email_verified claim. When an OIDC identity provider is configured with trustEmail=true and the userinfo endpoint is enabled, Keycloak retrieves the email address from the userinfo response but retrieves the email_verified status exclusively from the id_token. The root cause is a lack of validation ensuring that the email_verified claim in the id_token actually refers to the email address returned by the userinfo endpoint. If these two sources return different email addresses, the id_token's email_verified=true claim is blindly applied to the userinfo email. Exploitation Conditions: The OIDC identity provider must have trustEmail set to true (non-default). The userinfo endpoint must be enabled (default). The attacker must control or have compromised the upstream OIDC provider. Concrete Impact: Mark arbitrary email addresses as verified in the Keycloak database. Bypass email-based security controls or verification workflows. Potential account takeover if the application relies solely on the email_verified flag from the IdP to link accounts. | ||||
| CVE-2017-12159 | 2 Keycloak, Redhat | 5 Keycloak, Enterprise Linux Server, Jboss Single Sign On and 2 more | 2025-04-20 | N/A |
| 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. | ||||
| CVE-2017-12158 | 2 Keycloak, Redhat | 5 Keycloak, Enterprise Linux Server, Jboss Single Sign On and 2 more | 2025-04-20 | N/A |
| It was found that Keycloak would accept a HOST header URL in the admin console and use it to determine web resource locations. An attacker could use this flaw against an authenticated user to attain reflected XSS via a malicious server. | ||||
| CVE-2017-2585 | 1 Redhat | 5 Enterprise Linux Server, Jboss Single Sign On, Keycloak and 2 more | 2024-11-21 | N/A |
| Red Hat Keycloak before version 2.5.1 has an implementation of HMAC verification for JWS tokens that uses a method that runs in non-constant time, potentially leaving the application vulnerable to timing attacks. | ||||
| CVE-2016-8629 | 1 Redhat | 5 Enterprise Linux Server, Jboss Single Sign On, Keycloak and 2 more | 2024-11-21 | N/A |
| Red Hat Keycloak before version 2.4.0 did not correctly check permissions when handling service account user deletion requests sent to the rest server. An attacker with service account authentication could use this flaw to bypass normal permissions and delete users in a separate realm. | ||||
Page 1 of 1.