CVE-2025-11419: 
Java vulnerability analysis and mitigation

CVE-2025-11419 is a Denial of Service (DoS) vulnerability in Keycloak caused by the default JDK setting that permits Client-Initiated Renegotiation in TLS 1.2. An unauthenticated remote attacker can repeatedly initiate TLS renegotiation requests to exhaust server CPU resources, rendering the service unavailable. The vulnerability affects org.keycloak:keycloak-quarkus-dist versions prior to 26.0.16, 26.2.10, and 26.4.1, and was published on October 27, 2025, with NVD publication on December 23, 2025. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Github Advisory).

The root cause is the default JDK behavior that allows TLS 1.2 client-initiated renegotiation without restriction, classified under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-400 (Uncontrolled Resource Consumption). An unauthenticated attacker can establish a TLS connection to the Keycloak server and repeatedly send renegotiation requests; each renegotiation triggers a computationally expensive cryptographic handshake on the server side, progressively exhausting CPU resources. No authentication or special privileges are required, and the attack can be launched from any network-accessible location with low complexity (GitHub Advisory, Github Advisory).

Successful exploitation results in a complete availability impact on the Keycloak service, with no effect on confidentiality or integrity. Because Keycloak serves as a central identity and access management (IAM) platform, its unavailability can disrupt authentication and single sign-on (SSO) for all dependent applications and services, potentially causing widespread service outages across an organization. There is no risk of data exfiltration or unauthorized modification, but prolonged attacks could cause significant operational downtime (GitHub Advisory, Red Hat RHSA-2025:18254).

1. Reconnaissance: Identify internet-facing Keycloak instances running versions prior to 26.0.16, 26.2.10, or 26.4.1 using tools like Shodan or Censys, targeting HTTPS endpoints (typically port 8443 or 443).
2. Establish TLS 1.2 connection: Initiate a TLS 1.2 connection to the Keycloak server using a TLS client tool (e.g., openssl s_client -connect <host>:<port> -tls1_2).
3. Trigger renegotiation: Send repeated TLS renegotiation requests within the established session (e.g., using OpenSSL's R command in interactive mode or scripted tools that issue SSL_renegotiate() calls).
4. Exhaust CPU resources: Repeat the renegotiation requests at high frequency from one or multiple sources to force the server to perform repeated expensive cryptographic handshake operations, degrading or denying service to legitimate users (GitHub Advisory).

• Network: Unusually high volume of TLS handshake/renegotiation requests to Keycloak HTTPS ports (8443/443) from one or multiple source IPs; sustained spikes in TLS session establishment rates without corresponding application-layer activity.
• System: Sustained high CPU utilization on the Keycloak server process (Java/JVM) without a corresponding increase in authenticated sessions or application requests.
• Logs: Keycloak or JVM logs showing repeated TLS handshake events or SSL renegotiation entries in rapid succession; potential timeout or connection error messages from downstream services relying on Keycloak for authentication.

Keycloak has released patched versions 26.0.16, 26.2.10, and 26.4.1 for the org.keycloak:keycloak-quarkus-dist package; upgrading to one of these versions is the recommended long-term fix (GitHub Advisory). As an immediate workaround, administrators should add the Java system property -Djdk.tls.rejectClientInitiatedRenegotiation=true to the Keycloak startup configuration to disable client-initiated TLS renegotiation at the JDK level. Red Hat has also released corresponding security advisories (RHSA-2025:18254, RHSA-2025:18255, RHSA-2025:18889, RHSA-2025:18890) for Red Hat build of Keycloak 26.0.16 (Red Hat RHSA-2025:18254, Red Hat RHSA-2025:18255).

Red Hat rated this vulnerability as "Important" severity and issued multiple errata for its Keycloak product line, reflecting the significance of the issue for enterprise deployments (Red Hat RHSA-2025:18254). The vulnerability was noted in the CISA weekly vulnerability bulletin for the week of December 22, 2025. Community discussion has been limited, with no notable researcher commentary or significant social media debate beyond standard CVE tracking posts.