Red Hat Security Advisory: Red Hat build of Keycloak 26.6.3 Update
🔗 CVE IDs covered (14)
📋 Description
CVE-2026-4874 — org.keycloak.protocol.oidc.grants: org.keycloak.services.managers: Keycloak: Server-Side Request Forgery via OIDC token endpoint manipulation CVE-2026-7500 — org.keycloak.keycloak-services: Improper Access Control on Keycloak Server when the account Account API feature is disabled CVE-2026-8830 — keycloak: org.keycloak/keycloak-services: Keycloak: Policy bypass during WebAuthn credential registration via client-side JavaScript manipulation CVE-2026-8922 — org.keycloak/keycloak-services: keycloak: org.keycloak.protocol.oidc: Security flaw in org.keycloak/keycloak-services CVE-2026-9087 — keycloak: Cross-Session Email Verification Proof Not Bound to Upstream Identity in First-Broker-Login CVE-2026-9088 — keycloak: Keycloak: Information disclosure due to user profile permission bypass CVE-2026-9704 — keycloak: Keycloak: Privilege escalation due to oversized subject_token JWT CVE-2026-9791 — keycloak-rhel9: Organization Data Leak After Feature Disabled in Keycloak CVE-2026-9792 — keycloak: Keycloak: Security restriction bypass allows unauthorized ROPC token acquisition CVE-2026-9794 — keycloak: Keycloak: Information disclosure via SAML ECP endpoint CVE-2026-9801 — keycloak: Keycloak: Denial of Service via malformed LDAP password policy response CVE-2026-9802 — keycloak: Keycloak: Unauthorized account access via replayed refresh tokens after cluster restart CVE-2026-9803 — keycloak: Keycloak: Denial of Service via malformed Authorization header CVE-2026-37977 — keycloak: org.keycloak.protocol.oidc.grants.ciba: Keycloak: Information disclosure via CORS header injection due to unvalidated JWT azp claim
🎯 Affected products1
- Red Hat build of Keycloak 26.6.3
✅ 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: 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: 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 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 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: 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 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.