CVE-2025-2559: Keycloak JWT Token Caching DoS Vulnerability

CVE-2025-2559 Overview

A flaw exists in Keycloak's JWT token handling that can lead to a denial of service condition. When Keycloak is configured to use JSON Web Tokens (JWT) for client authentication, the tokens are cached until their expiration time. Clients that issue JWTs with excessively long expiration windows, such as 24 or 48 hours, cause the cache to grow without bound. This unbounded growth exhausts JVM heap memory and triggers an OutOfMemoryError, preventing legitimate authentication requests from being processed. The weakness is classified under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
An authenticated client can trigger memory exhaustion in the Keycloak server, causing service-wide denial of service that blocks all users from authenticating.

Affected Products

Red Hat build of Keycloak (see Red Hat Security Advisory RHSA-2025:4335)
Red Hat Single Sign-On / Keycloak upstream (see Red Hat Security Advisory RHSA-2025:4336)
Keycloak deployments configured with Signed JWT or Signed JWT with Client Secret authentication

Discovery Timeline

2025-03-25 - CVE-2025-2559 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-2559

Vulnerability Analysis

Keycloak accepts JWT tokens for client authentication when clients are configured with the Signed JWT or Signed JWT with Client Secret credential types. To prevent token replay, Keycloak retains presented tokens in an in-memory cache and holds each entry until the token's exp (expiration) claim passes. The server does not enforce an upper bound on how far in the future exp may be set. A client can therefore issue tokens whose expiration is many hours or days away, and each authentication call adds a long-lived entry to the cache. Over time, or under a burst of authentications, the cache consumes all available heap. The Java Virtual Machine (JVM) then throws an OutOfMemoryError and the authentication service becomes unavailable.

Root Cause

The root cause is missing input validation on the token expiration window. Keycloak trusts the client-supplied exp claim to size the cache retention period. Without a server-enforced maximum, the resource lifetime is fully attacker-controlled, which is the classic [CWE-770] pattern of unbounded resource allocation.

Attack Vector

The attack requires network access to the Keycloak authentication endpoint and valid client credentials configured to use JWT authentication. An attacker with a compromised or misconfigured confidential client repeatedly authenticates using freshly issued JWTs that carry very long expiration times. Each request pins a new cache entry until heap memory is exhausted.

The upstream patch adds a Max expiration configuration option that caps how old, and by extension how long-lived, an accepted JWT may be. Documentation from the fix commit describes the new behavior:

text

When a client is configured to authenticate using the Signed JWT or
Signed JWT with Client Secret type, Keycloak now enforces a maximum
expiration for the token. This means that, although the exp
(expiration) claim in the token may be much later, Keycloak will not
accept tokens issued before that max expiration time. The default
value is 60 seconds. Note that JWT tokens should be issued right
before being sent for authentication.

Source: GitHub Keycloak Commit a10c811

Detection Methods for CVE-2025-2559

Indicators of Compromise

Repeated OutOfMemoryError entries or JVM heap dumps in Keycloak server logs correlated with authentication activity.
Authentication requests from a single client presenting JWTs with exp values many hours or days in the future.
Sustained growth of the Keycloak process resident memory without a corresponding increase in active user sessions.

Detection Strategies

Parse Keycloak access logs for client_assertion JWT authentications and extract the exp claim to flag tokens with expirations longer than the intended issuance window (default 60 seconds after the fix).
Alert on Keycloak JVM heap usage trending toward configured maximums, especially when tied to token authentication traffic.
Correlate authentication volume per client with heap growth to identify clients driving cache pressure.

Monitoring Recommendations

Enable JVM garbage collection and heap metrics through JMX or the Keycloak metrics endpoint and forward them to a centralized monitoring system.
Track the count of unique client authentication events per minute and per client identifier.
Configure availability probes against /realms/{realm}/protocol/openid-connect/token so denial-of-service conditions are surfaced quickly.

How to Mitigate CVE-2025-2559

Immediate Actions Required

Apply the updates in RHSA-2025:4335 and RHSA-2025:4336 to affected Keycloak deployments.
Audit all confidential clients using Signed JWT authentication and configure the new Max expiration value in the client Credentials tab.
Rotate credentials for any client suspected of issuing long-lived JWTs against production Keycloak instances.

Patch Information

The upstream fix is delivered in Keycloak commit a10c811 and tracked in Keycloak issue #38576. It introduces a Max expiration setting on Signed JWT and Signed JWT with Client Secret authenticators, defaulting to 60 seconds. Red Hat customers should install the packages from RHSA-2025:4335 or RHSA-2025:4336 as appropriate. Additional vendor context is available in the Red Hat CVE record for CVE-2025-2559 and Red Hat Bugzilla #2353868.

Workarounds

Until patching is possible, require clients to issue JWTs immediately before authentication with an exp no more than 60 seconds in the future.
Restrict network access to Keycloak client authentication endpoints so only trusted client networks can reach them.
Increase JVM heap sizing and configure automatic restarts as a stopgap to shorten outage duration if the cache fills.

bash

# Configuration example: set Max expiration on a Signed JWT client via kcadm
kcadm.sh update clients/<client-uuid> \
  -r <realm> \
  -s 'attributes."token.endpoint.auth.signing.max.exp"=60'