CVE-2025-11419: Keycloak TLS DoS Vulnerability

CVE-2025-11419 Overview

A denial of service vulnerability has been identified in Keycloak, the popular open-source identity and access management solution. This flaw allows an unauthenticated remote attacker to cause a denial of service (DoS) by repeatedly initiating TLS 1.2 client-initiated renegotiation requests. By exploiting this weakness, attackers can exhaust server CPU resources, rendering the authentication service unavailable to legitimate users.

Critical Impact

Unauthenticated attackers can remotely crash or degrade Keycloak authentication services by exhausting CPU resources through repeated TLS 1.2 renegotiation requests, potentially disrupting authentication for all dependent applications.

Affected Products

• Keycloak (versions prior to patched releases)
• Red Hat Single Sign-On (based on Keycloak)
• Red Hat Build of Keycloak

Discovery Timeline

• 2025-12-23 - CVE-2025-11419 published to NVD
• 2026-04-20 - Last updated in NVD database

Technical Details for CVE-2025-11419

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue lies in Keycloak's handling of TLS 1.2 client-initiated renegotiation requests. TLS renegotiation is a legitimate protocol feature that allows either party to request new cryptographic parameters during an established session. However, the asymmetric computational cost between client and server creates an exploitable condition.

When a client initiates renegotiation, the server must perform computationally expensive cryptographic operations. Without proper rate limiting or restrictions on renegotiation requests, an attacker can send a continuous stream of renegotiation requests, forcing the server to consume excessive CPU cycles. This resource exhaustion attack does not require authentication, making it particularly dangerous as any network-accessible attacker can launch the assault.

Root Cause

The root cause is the absence of adequate resource allocation controls when processing TLS 1.2 client-initiated renegotiation requests. Keycloak's underlying TLS implementation fails to impose limits on the frequency or total number of renegotiation requests that can be processed from a single client connection. This allows malicious actors to abuse the computationally expensive handshake process without restriction.

The TLS 1.2 renegotiation mechanism inherently requires significant server-side computation for cryptographic operations including key exchange and certificate verification. Without throttling mechanisms, the server becomes vulnerable to CPU exhaustion attacks where minimal client resources can consume disproportionate server resources.

Attack Vector

This vulnerability is exploitable over the network without requiring any authentication or user interaction. An attacker can exploit this flaw by:

1. Establishing a TLS 1.2 connection to the Keycloak server
2. Repeatedly sending TLS renegotiation requests on the same connection
3. Optionally opening multiple connections to amplify the attack

The attack takes advantage of the computational asymmetry in TLS handshakes—a client can request renegotiation with minimal CPU cost while the server must perform expensive cryptographic operations. By flooding the server with these requests, the attacker can exhaust available CPU resources, causing service degradation or complete unavailability.

Since this attack targets the TLS layer before application-level authentication occurs, standard application security controls are bypassed.

Detection Methods for CVE-2025-11419

Indicators of Compromise

• Abnormally high CPU utilization on Keycloak servers without corresponding increase in legitimate authentication traffic
• Multiple TLS renegotiation events from single IP addresses or client connections in TLS/SSL logs
• Increased connection timeouts or authentication failures reported by dependent applications
• Elevated memory usage correlating with TLS session state management

Detection Strategies

• Monitor for excessive SSL_do_handshake() calls or TLS renegotiation events in server-side TLS logs
• Implement network-based detection for patterns of repeated ClientHello messages within established TLS sessions
• Configure alerting on Keycloak server CPU utilization thresholds, particularly when not correlated with increased user traffic
• Deploy intrusion detection system (IDS) rules to identify TLS renegotiation abuse patterns

Monitoring Recommendations

• Enable detailed TLS handshake logging to track renegotiation frequency per client connection
• Implement real-time monitoring of CPU usage on Keycloak application servers with automated alerting
• Track connection duration and renegotiation counts per session using network monitoring tools
• Establish baseline metrics for normal TLS handshake patterns to identify anomalous behavior

How to Mitigate CVE-2025-11419

Immediate Actions Required

• Apply the latest security patches from Red Hat for Keycloak and Red Hat Single Sign-On immediately
• Configure load balancers or reverse proxies to limit TLS renegotiation requests per connection
• Consider disabling client-initiated TLS renegotiation at the network level if not required for operations
• Implement rate limiting on incoming TLS connections to Keycloak servers

Patch Information

Red Hat has released multiple security advisories addressing this vulnerability. Organizations should apply the appropriate patches based on their deployment:

• Red Hat Security Advisory RHSA-2025:18254
• Red Hat Security Advisory RHSA-2025:18255
• Red Hat Security Advisory RHSA-2025:18889
• Red Hat Security Advisory RHSA-2025:18890

For additional technical details, refer to the Red Hat CVE Analysis and Red Hat Bug Report #2402142.

Workarounds

• Disable TLS 1.2 client-initiated renegotiation at the reverse proxy or load balancer level using appropriate configuration directives
• Deploy Keycloak behind a web application firewall (WAF) with TLS renegotiation attack detection capabilities
• Implement connection rate limiting at the network perimeter to restrict the number of TLS handshakes from individual source IPs
• Consider upgrading to TLS 1.3 where possible, as it eliminates the client-initiated renegotiation feature entirely

# Example: Disable client-initiated renegotiation in Nginx reverse proxy
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

# In Nginx 1.15.0+, renegotiation is disabled by default
# For older versions or explicit control, use:
# proxy_ssl_session_reuse off;

# Rate limiting for TLS connections
limit_conn_zone $binary_remote_addr zone=ssl_conn:10m;
limit_conn ssl_conn 10;