Search
Search Results (27 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-18206 | 1 Redhat | 8 Build Keycloak, Build Of Keycloak, Data Grid and 5 more | 2026-08-02 | 3.7 Low |
| A flaw was found in the keycloak-services component of Keycloak, which provides identity and access management services. The issue occurs when a realm administrator uses a wildcard domain (like *.example.com) to restrict which hosts can register or update clients. Due to improper validation, the system accepts any hostname that ends with the specified domain suffix, even if it is not a legitimate subdomain. An attacker who can control the reverse DNS of their connection can bypass these host-based restrictions, potentially allowing unauthorized client modifications. | ||||
| CVE-2026-18209 | 1 Redhat | 8 Build Keycloak, Build Of Keycloak, Data Grid and 5 more | 2026-08-02 | 3.4 Low |
| A flaw was found in the keycloak-services component of Keycloak, which handles OpenID Connect (OIDC) authentication flows. The issue occurs because the security check designed to prevent HTTP parameter pollution only inspects the query portion of a redirect URL and ignores the fragment portion. When a client is configured with a wildcard redirect URI, an attacker can use this to inject duplicate security parameters into the login response. If a client application is not configured correctly, it might trust the attacker's injected data instead of the real security information from Keycloak, leading to session fixation or account confusion. | ||||
| 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. | ||||