CVE-2025-11419: Red Hat Keycloak TLS Client-Initiated Renegotiation DoS

Aegiron 10 mins0

Vulnerability Header

AttributeDetails
CVE IDCVE-2025-11419
CVSS Score7.5 (High)
SeverityHigh / Important
PublishedDecember 24, 2025
Vulnerability TypeDenial of Service (DoS)
Attack VectorNetwork
Attack ComplexityLow
Privileges RequiredNone
User InteractionNone
ImpactService Availability

Vulnerability Overview

CVE-2025-11419 is a denial-of-service vulnerability affecting the Red Hat build of Keycloak. The issue allows a remote, unauthenticated attacker to exhaust server CPU resources by repeatedly triggering TLS client-initiated renegotiation.

Keycloak permits TLS 1.2 renegotiation requests on an established connection without sufficient restriction. Each renegotiation forces the server to perform computationally expensive cryptographic operations, including key exchange, cipher negotiation, and verification. By repeatedly requesting renegotiation on a single connection, an attacker can consume disproportionate CPU resources with minimal effort.

The attacker does not need credentials, valid authentication attempts, or even application-layer requests. Network access to the TLS port is sufficient. Over time, CPU utilization reaches saturation, legitimate authentication traffic times out, and the Keycloak service becomes unavailable.

Affected Versions

The following Red Hat build of Keycloak versions are vulnerable:

  • Red Hat Keycloak 26.0 through 26.0.15
  • Red Hat Keycloak 26.1.x
  • Red Hat Keycloak 26.2.0 through 26.2.9
  • Red Hat Keycloak 26.3.x
  • Red Hat Keycloak 26.4.0

Patched Versions

  • Red Hat Keycloak 26.0.16 and later
  • Red Hat Keycloak 26.2.10 and later
  • Red Hat Keycloak 26.4.1 and later

Technical Details: How the Vulnerability Works

Attack Mechanism

  1. The attacker establishes a normal TLS connection to the Keycloak server.
  2. The initial TLS handshake completes successfully.
  3. The attacker sends a TLS renegotiation request on the same connection.
  4. Keycloak performs a full TLS handshake again.
  5. The attacker repeats this process continuously.

Each renegotiation forces expensive cryptographic operations on the server. The attacker only sends small protocol messages, creating a large asymmetry between attacker effort and server workload.

Why This Works

  • Asymmetric computation: Server-side TLS operations are significantly more expensive than client requests.
  • Single-connection abuse: The attack does not require multiple connections, bypassing common rate-limiting defenses.
  • No authentication: No credentials or valid sessions are required.
  • Minimal bandwidth: Very low traffic volume is sufficient to exhaust CPU.

Exploitation Scenario

An organization operates Keycloak as its central SSO platform. An attacker identifies the authentication endpoint and opens TLS connections to the HTTPS port.

Instead of sending login requests, the attacker repeatedly triggers TLS renegotiation. The Keycloak server continuously performs cryptographic work, rapidly consuming CPU resources. Authentication requests begin to time out, users are unable to log in, and all dependent applications experience outages.

The attack is low-noise, low-bandwidth, and difficult to detect using traditional volumetric DoS controls.

Detection Methods

1. Network-Level Detection

Testing with OpenSSL

openssl s_client -connect keycloak-server[.]example[.]com:443 -tls1_2
# After the connection establishes, type: R
# If renegotiation succeeds, the server is vulnerable
# If the server disconnects or errors, mitigation or patch is applied

Behavior Indicators

  • Multiple renegotiations accepted on a single connection
  • No rejection or throttling of renegotiation attempts
  • Repeated TLS handshakes without connection resets

2. System-Level Detection Signals

CPU Metrics

  • Sustained 90–100% CPU usage on Keycloak processes
  • CPU spikes without corresponding increases in authentication traffic
  • Java processes consuming abnormal CPU

Network Metrics

  • High packet rate on ports 443/8443
  • Established connections generating large numbers of TLS records
  • Repeated handshake messages on a single TCP connection

Application Metrics

  • Increased TLS handshake processing time
  • Authentication request timeouts
  • Login error rates spike while other services remain healthy

3. Traffic Pattern Analysis

In Wireshark or similar tools:

  • Multiple ClientHello messages from the same source on one connection
  • Rapid renegotiation attempts
  • TLS renegotiation extensions repeatedly present

4. Log Analysis

Keycloak Logs

# High volume of TLS warnings
# Repeated SSL handshake messages
# Renegotiation-related errors from same source IP

Java / System Logs

# SSL_ERROR_* messages
# javax.net.ssl renegotiation exceptions
# Stack traces showing SSL in network I/O threads

Payload / Attack Demonstration

import ssl
import socket

target_host = "keycloak[.]example[.]com"
target_port = 443

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
context = ssl.create_default_context()
ssock = context.wrap_socket(sock, server_hostname=target_host)
ssock.connect((target_host, target_port))

for i in range(10000):
    ssock.do_handshake()
    print(f"Renegotiation {i} sent")

ssock.close()

Attack Characteristics

  • Operates entirely at the TLS layer
  • No application-layer traffic required
  • Extremely low bandwidth
  • High CPU impact

Detection Rules and Signatures

IDS / IPS (Suricata / Snort)

alert tls $HOME_NET any -> $EXTERNAL_NET [443,8443] (
  msg:"Potential TLS Renegotiation DoS Attack";
  flow:to_server,established;
  tls.client_hello;
  threshold:type by_src, track by_src, count 50, seconds 10;
  sid:1000001;
  rev:1;
)

Log Sources for Monitoring

  1. Keycloak Logs
    • keycloak.log
    • server.log
  2. Operating System Logs
    • /var/log/auth.log
    • syslog / journalctl
  3. Network Device Logs
    • Firewall logs
    • Load balancer logs
  4. Java Runtime Logs
    • SSL/TLS debug output
    • GC logs
  5. Container / Orchestration Logs
    • Docker logs
    • Kubernetes pod metrics

Official Patch Information

Official Red Hat Resources

Patch Versions

  • 26.0.16+
  • 26.2.10+
  • 26.4.1+

Patch Release Date: October 16, 2025
Public Disclosure: December 24, 2025

Patching Steps

Standalone Deployment

systemctl stop keycloak
cp -r /opt/keycloak /opt/keycloak.backup
tar -xzf keycloak-26.0.16.tar.gz
systemctl start keycloak

Verify:

/opt/keycloak/bin/kc.sh -version

Containerized Deployment

image: registry.redhat.io/rhbk/keycloak-rhel9:26.0.16

docker-compose up -d
kubectl rollout status deployment/keycloak

Mitigation and Workarounds

JVM-Level Mitigation

-Djdk.tls.rejectClientInitiatedRenegotiation=true

Network-Level Controls

Nginx

limit_conn_zone $binary_remote_addr zone=tls_limit:10m;
limit_conn tls_limit 10;

iptables

iptables -A INPUT -p tcp --dport 443 -m limit --limit 50/second -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

CVSS and Risk Assessment

Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Risk Level: HIGH / IMPORTANT

Final Takeaway

CVE-2025-11419 is dangerous because it is simple, quiet, and effective. A single unauthenticated client can exhaust Keycloak’s CPU by abusing TLS renegotiation, taking down authentication services and everything that depends on them.

The mitigation is straightforward: patch immediately or disable client-initiated TLS renegotiation at the JVM level. Any organization running Keycloak—especially internet-facing deployments—should treat this as an urgent availability risk.

If you have not patched or applied mitigations, you are exposed.

Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.