Red Hat Security Advisory: Red Hat build of Keycloak 26.4.16 Security Update
🔗 CVE IDs covered (7)
📋 Description
CVE-2026-17526 — keycloak-services: keycloak-services: Privilege escalation via impersonation role allows takeover of realm administrator accounts CVE-2026-18212 — keycloak-services: keycloak-services: SAML Redirect DEFLATE helpers leak native zlib state CVE-2026-19607 — keycloak-services: keycloak-services: Broker-originated username collision causes account lockout CVE-2026-19729 — keycloak-services: keycloak-services: Incomplete fix for arbitrary filesystem path probing via keystore parameters CVE-2026-62243 — io.netty/netty-handler: Netty: TLS hostname verification bypass via OpenSSL client path misconfiguration CVE-2026-74909 — keycloak-services: keycloak-services: Incomplete fix for CVE-2026-15573 allows policy enforcer bypass via percent-encoded URI segments CVE-2026-79651 — keycloak-services: keycloak-services: unauthenticated DoS via unbounded locale caching
🎯 Affected products1
- Red Hat build of Keycloak 26.4.16
✅ 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 do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: This vulnerability only affects applications that explicitly configure Netty to use the OpenSSL TLS provider (SslProvider.OPENSSL). The following mitigations can reduce exposure without applying a patch: 1) Use the default JDK SSL provider — Do not configure SslProvider.OPENSSL in your Netty SslContext setup. The default JDK SSL provider (SslProvider.JDK) is not affected by this vulnerability. Most applications use the JDK default unless explicitly overridden. 2) Use X509ExtendedTrustManager — If the OpenSSL provider is required, ensure the configured trust manager extends X509ExtendedTrustManager rather than the plain X509TrustManager interface. The extended variant performs hostname verification independently of the Netty wrapping logic. 3) Run on Java 24 or earlier — The vulnerable code path only triggers on Java 25+ where sun.misc.Unsafe-based trust-manager wrapping is unavailable. Running on earlier Java versions (e.g., Java 21 LTS) means the wrapping works correctly and hostname verification stays enabled.