Red Hat Security Advisory: Red Hat build of Keycloak 26.4.13 Security Update

🔗 CVE IDs covered (22)

📋 Description

🎯 Affected products1

• Red Hat build of Keycloak 26.4.13

✅ Remediation

Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on. Workaround: Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: To reduce the attack surface, restrict network access to the Keycloak server's administration and API endpoints to trusted networks or hosts. This limits the ability of unauthorized users to interact with the server and potentially exploit this improper access control vulnerability. If the Keycloak service is reloaded or restarted, ensure that firewall rules or network access controls remain in effect. Workaround: Ensure that only highly trusted administrators are granted the "manage-realm" role within Keycloak. This role provides extensive administrative privileges, including the ability to exploit this vulnerability for filesystem probing. Regularly review and audit users assigned to this role to minimize the attack surface. Workaround: To mitigate this vulnerability, restrict the ability to register new clients and manage existing client configurations. If Dynamic Client Registration is not required, disable it in Keycloak's Realm Settings under Client Registration Policies. If Dynamic Client Registration is necessary, ensure that policies are strictly configured to prevent anonymous client registration and require initial access tokens for all client registrations. Additionally, limit the `manage-client` role to only trusted administrators. Changes to Keycloak configuration may require a service restart or redeployment to take effect. Workaround: To mitigate this issue, configure the affected identity provider to set `trustEmail=true`. This ensures that Keycloak trusts the email address provided by the upstream identity provider, bypassing the vulnerable verification flow. This mitigation should only be applied if the upstream identity provider is fully trusted to verify email addresses and prevent malicious account creation with existing email addresses. Configuration changes may require a Keycloak service restart or reload to take effect. Workaround: To mitigate this issue, restrict network access to the Keycloak Admin REST API to only trusted networks or localhost. This limits the attack surface by preventing unauthorized access to the API endpoints required for exploitation. Consult your network security documentation for specific firewall or network access control configurations. This may impact remote administration capabilities. Workaround: To prevent the silent dropping of oversized `subject_token` JWTs, configure Keycloak to enforce strict parameter validation. This involves setting the `fail-fast` parameter to `true` for the `TokenEndpoint` configuration, which will cause requests with oversized parameters to be rejected explicitly rather than silently processed with reduced privileges. Consult Keycloak documentation for the exact method to modify these settings. A restart of the Keycloak service may be necessary for the changes to apply. Workaround: To mitigate this issue, restrict network access to the Keycloak Dynamic Client Registration endpoint. Configure network firewalls to allow connections only from trusted hosts or networks that legitimately require access to this functionality. This limits the exposure of the vulnerable endpoint to unauthorized access attempts. Workaround: Administrators should verify that disabling the Organizations feature properly blocks all organization-related functionality. Consider implementing additional access controls or removing organization memberships before disabling the feature. Workaround: To mitigate this issue, Keycloak administrators should review and adjust client policies designed to reject Resource Owner Password Credentials (ROPC) grants. Avoid using the `client-type`, `client-roles`, `client-attributes`, or `client-scopes` condition providers in conjunction with the `reject-ropc-grant` executor. Instead, configure policies to use the `grant-type` condition provider for ROPC rejection. A restart or reload of the Keycloak service may be required for these policy changes to take full effect. Workaround: To mitigate this issue, disable the Fine-Grained Admin Permissions (FGAPv2) feature in Keycloak if it is not strictly required. This can typically be done by setting `adminPermissionsEnabled` to `false` in the realm configuration. Disabling FGAPv2 will prevent the exploitation of this flaw by removing the vulnerable functionality. However, this may impact administrative delegation capabilities within Keycloak. A restart or reload of the Keycloak service may be required for the changes to take effect. Workaround: To mitigate this issue, ensure that the Keycloak client's policy enforcement mode is set to ENFORCING instead of PERMISSIVE. The PERMISSIVE mode is a non-default configuration that enables the vulnerability. Changing this setting will prevent the unauthorized access to resources of the same type. Consult Keycloak documentation for specific instructions on configuring policy enforcement mode for your client. This change may require a restart or reload of the Keycloak service to take effect and could impact existing authorization policies if not carefully managed. Workaround: To mitigate this vulnerability, ensure that Keycloak's LDAP user-storage providers are configured to connect only to trusted and secure LDAP servers. Avoid configuring LDAP federation with unverified or potentially malicious LDAP endpoints. Additionally, always use TLS for LDAP connections to prevent Man-in-the-Middle attacks. If an upstream LDAP server is compromised, it should be isolated and secured immediately.

🔗 References (3)

• selfhttps://access.redhat.com/errata/RHSA-2026:30049
• externalhttps://access.redhat.com/security/updates/classification/#important
• selfhttps://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_30049.json