Skip to main content

Red Hat CVE-2025-11419

HIGH
Allocation of Resources Without Limits or Throttling (CWE-770)
2025-12-23 secalert@redhat.com GHSA-q8hq-4h99-fj7x
7.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Red Hat
7.5 HIGH
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

1
Analysis Generated
Apr 20, 2026 - 18:28 vuln.today

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 12 maven packages depend on org.keycloak:keycloak-quarkus-dist (1 direct, 11 indirect)

Ecosystem-wide dependent count for version 26.1.0.

DescriptionCVE.org

A flaw was found in Keycloak. This vulnerability allows an unauthenticated remote attacker to cause a denial of service (DoS) by repeatedly initiating TLS 1.2 client-initiated renegotiation requests to exhaust server CPU resources, making the service unavailable.

AnalysisAI

TLS renegotiation exhaustion in Keycloak allows unauthenticated remote denial of service via repeated client-initiated TLS 1.2 renegotiation requests that drain CPU resources. Affects Red Hat Single Sign-On deployments using TLS 1.2 with client renegotiation enabled. EPSS exploitation probability and KEV status not available at analysis time; CVSS 7.5 (High) reflects network-accessible attack with low complexity but availability impact only. Red Hat has issued multiple security advisories (RHSA-2025:18254, 18255, 18889, 18890) addressing this flaw.

Technical ContextAI

Keycloak is an open-source identity and access management solution. This vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) exploits TLS 1.2's client-initiated renegotiation feature, which allows clients to request a new key exchange during an existing session. Without proper rate limiting or resource controls, an attacker can repeatedly trigger these CPU-intensive cryptographic operations. Each renegotiation request forces the server to perform expensive handshake computations (certificate verification, key derivation, cipher negotiation) without establishing new connections, bypassing connection-based rate limiting. The issue is specific to TLS 1.2; TLS 1.3 removed support for renegotiation entirely. Affected components include the Keycloak server's TLS termination layer when configured to accept TLS 1.2 connections with client renegotiation enabled, which may be the default in some Red Hat Single Sign-On distributions.

Affected ProductsAI

Red Hat Single Sign-On and upstream Keycloak deployments supporting TLS 1.2 with client-initiated renegotiation enabled. Red Hat Security Advisories RHSA-2025:18254, RHSA-2025:18255, RHSA-2025:18889, and RHSA-2025:18890 indicate affected product versions across multiple Red Hat product streams. Specific version ranges are not detailed in provided references, but GitHub issue 43020 and discussion 25209 (https://github.com/keycloak/keycloak/issues/43020, https://github.com/keycloak/keycloak/discussions/25209) indicate upstream Keycloak awareness. CPE data not provided in input, but affected products include Red Hat SSO 7.x series and corresponding upstream Keycloak versions supporting TLS 1.2. Consult Red Hat advisory links for complete version mapping: https://access.redhat.com/errata/RHSA-2025:18254.

RemediationAI

Apply vendor patches released in Red Hat Security Advisories RHSA-2025:18254, RHSA-2025:18255, RHSA-2025:18889, or RHSA-2025:18890 depending on your Red Hat product version (https://access.redhat.com/errata/RHSA-2025:18254). For upstream Keycloak users, monitor GitHub issue 43020 for patch commits and update to the fixed version when released. If immediate patching is not feasible, implement the following compensating controls with noted trade-offs: (1) Disable TLS 1.2 and enforce TLS 1.3-only connections in the TLS configuration, which eliminates renegotiation support entirely - trade-off: may break compatibility with legacy clients requiring TLS 1.2; (2) Configure the TLS termination layer (reverse proxy, load balancer, or application server) to disable client-initiated renegotiation while maintaining TLS 1.2 support - trade-off: requires infrastructure access and may not be supported by all TLS implementations; (3) Deploy rate limiting at the network edge (WAF, DDoS protection service) to restrict connection attempts per source IP - trade-off: distributed attacks from multiple IPs may still succeed, and legitimate users behind NAT may be affected. Combine multiple mitigations for defense-in-depth.

Vendor StatusVendor

Share

CVE-2025-11419 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy