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:

Establishing a TLS 1.2 connection to the Keycloak server
Repeatedly sending TLS renegotiation requests on the same connection
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:

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

bash

# 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;