Overview of CVE-2026-107123: Unauthenticated CPU Exhaustion in Keycloak SAML dateTime and Duration Parsing

Introduction

Keycloak sits in front of the login flow for many applications, so anything that stalls its request processing stalls authentication for every user and service behind it. CVE-2026-107123 is that kind of issue. An unauthenticated sender can push oversized XML time values into Keycloak's SAML endpoints and make the server spend quadratic CPU time parsing them.

Keycloak is an open-source identity and access management project created in 2014 by Bill Burke and Stian Thorgersen, and accepted into the CNCF at the Incubating level on April 10, 2023. CNCF's 2023 announcement names production users including Accenture, CERN, Cisco, Hitachi, Okta, and the Ohio Supercomputing Center. Red Hat ships a commercial, supported distribution called Red Hat Build of Keycloak based on the community project, and Red Hat is the CNA for this CVE.

Red Hat scores the issue CVSS 3.1 7.5 High with a product severity of Important. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H: network reachable, low complexity, no privileges, no user interaction, and impact limited to availability. This is a CNA score. NVD lists its own assessment as unavailable while the record awaits enrichment. Upstream Keycloak has a public fix in 26.8.2.

Technical information

Root cause

SAML messages carry many XML time values, such as xs:dateTime timestamps and xs:duration values. Keycloak converts these strings into Java objects in one shared helper, XMLTimeUtil (saml/v2/util/XMLTimeUtil.java in the SAML core module), which hands them to javax.xml.datatype.DatatypeFactory.

According to the comment added by the fix, DatatypeFactory.newXMLGregorianCalendar() and newDuration() parse their numeric components with BigDecimal(String) and BigInteger(String). Those constructors have O(n²) cost on very long inputs. A timestamp whose fractional seconds run to thousands of digits still looks like a syntactically plausible value, but parsing it is expensive. Before the patch, nothing limited the length of the string before this parse, so the cost of the operation was entirely under the sender's control. The patch comment links this to the same JDK behaviour behind CVE-2026-68497 in Jackson.

Red Hat's description summarizes it as improper validation of the lengths of dateTime and duration strings, and the assigned weakness is CWE-400, Uncontrolled Resource Consumption. Bugzilla files the issue under the Keycloak services component and org.keycloak.saml.

Reachable endpoints

The Red Hat Bugzilla entry documents three SAML endpoints that accept the crafted request via HTTP POST:

• /realms/{realm}/protocol/saml
• /realms/{realm}/broker/saml/endpoint
• /realms/{realm}/protocol/saml/resolve

Bugzilla states explicitly that exploitation needs no credentials, no valid client registration, and no valid SAML signature. Signature enforcement is therefore not a control here. Rejecting an unsigned or badly signed message does not mean the expensive time parsing was skipped.

Attack flow

Based on the advisory, the bug report, and the shape of the regression tests in the fix, the sequence looks like this:

1. The attacker identifies a network-reachable Keycloak instance and a realm name to place in the endpoint path.
2. The attacker builds SAML XML containing an excessively long temporal value, for example a dateTime with around 1,000 fractional-second digits, or a duration of the form P followed by 1,000 digits and Y (these are the input shapes the patch's tests reject).
3. The attacker sends the payload via HTTP POST to one of the three endpoints above. No session, client, or signature is needed.
4. Keycloak routes the value through XMLTimeUtil into DatatypeFactory, where BigDecimal or BigInteger parsing burns CPU in proportion to the square of the input length.
5. Repeated requests keep CPU utilization high. Bugzilla describes sustained high CPU load and potentially total denial of service, with authentication and authorization flows becoming unresponsive for all users.

The sources do not give a complete payload, a minimum triggering length, the request rate needed to sustain the outage, or measured attack cost, so we are not putting numbers on those.

Exploitation status

The Red Hat advisory and Bugzilla report do not identify observed attacks, campaigns, or threat actors, and no public exploit code is provided. Red Hat credits Mohammed LACHHAB with reporting the issue. That is a reporter acknowledgment, not attribution. The CVE is absent from the retrieved CISA KEV snapshot (version 2026.11.04), but that snapshot predates publication, so it says little either way. Bugzilla records the initial report on October 7, 2026, and NVD lists publication on November 5, 2026.

Patch information

Upstream has a public fix in Keycloak 26.8.2, published on GitHub on November 5, 2026. The release lists #54690 [CVE-2026-107123] Unauthenticated DoS in Keycloak SAML endpoint under Security fixes. Issue #54690 is closed as completed and carries the labels release/26.8.2 and release/26.6.8, which suggests a backport to the 26.6 line. We checked only the 26.8.2 release.

The code change is commit 0206529f, Limit the length of dates and durations, by Alexander Schwartz (October 19, 2026). Its message ends with Closes CVE-2026-107123.

The fix leaves the JDK parser alone and adds a cheap length check in front of it, in the single helper that SAML time parsing goes through:

// DatatypeFactory.newXMLGregorianCalendar() and newDuration() internally parse numeric components
// via BigDecimal(String)/BigInteger(String) which have O(n^2) complexity for large inputs.
// A valid ISO 8601 dateTime or duration never exceeds ~40 characters; 100 is a generous upper bound.
// See CVE-2026-68497 (Jackson) for the underlying JDK issue.
static final int MAX_TIME_STRING_LENGTH = 100;

Both parsing entry points now call the guard first:

 public static Duration parseAsDuration(String timeValue) {
     if (timeValue == null) {
         PicketLinkLoggerFactory.getLogger().nullArgumentError("duration time");
     }
+    validateLength(timeValue, "duration");
     DatatypeFactory factory = DATATYPE_FACTORY.get();
 ...
 public static XMLGregorianCalendar parse(String timeString) {
+    validateLength(timeString, "dateTime");
     DatatypeFactory factory = DATATYPE_FACTORY.get();
     return factory.newXMLGregorianCalendar(timeString);
 }

+private static void validateLength(String value, String type) {
+    if (value != null && value.length() > MAX_TIME_STRING_LENGTH) {
+        throw new IllegalArgumentException("XML " + type + " value length (" + value.length()
+                + ") exceeds the maximum allowed (" + MAX_TIME_STRING_LENGTH + ")");
+    }
+}

Three design choices stand out:

• The check lives in the shared helper, XMLTimeUtil, rather than in each SAML endpoint, so one 15-line change covers every code path that parses a SAML date or duration through these methods.
• Rejection takes constant time. String.length() is effectively free, so an oversized value is refused before any BigDecimal work begins. The attacker's cost asymmetry disappears.
• The limit is generous. Real ISO 8601 values stay under about 40 characters, so a 100-character cap should not reject legitimate IdP or SP traffic. Oversized values fail fast with an IllegalArgumentException instead of being parsed.

The commit also adds XMLTimeUtilTest.java (113 lines):

• Normal values still parse: 2024-01-15T10:30:00.123Z, a +14:00 timezone offset, P1Y2M3DT4H5M6S, and the plain millisecond form 3600000.
• Malicious-style inputs are rejected with an exceeds the maximum allowed message: a dateTime with 1,000 fractional-second digits, and a duration of the form P plus 1,000 digits plus Y.
• Boundary tests confirm that a string of exactly MAX_TIME_STRING_LENGTH characters passes the check and one character more is rejected.

Version to run: Keycloak 26.8.2 or later. Red Hat Build of Keycloak users should watch the Red Hat CVE page for an erratum, since none has been issued yet. Red Hat's advisory also states that no mitigation meeting its criteria for ease of deployment, broad applicability, and stability is available, so there is no vendor-endorsed configuration workaround to apply in the meantime.

Affected systems and versions

• Upstream Keycloak: fixed in 26.8.2 (released November 5, 2026). The reviewed CVE record does not enumerate a separate upstream vulnerable range, so no lower bound can be stated. The release/26.6.8 label on issue #54690 suggests a 26.6.8 backport, but that release was not verified.
• Red Hat Build of Keycloak: listed in the CVE record with a default status of all versions affected, without an enumerated range. Red Hat's advisory lists its Keycloak services package and the RHBK RHEL 9 component as Affected, with no errata issued yet.
• Red Hat Single Sign On 7: Not affected. Red Hat states the vulnerable code is not present. This is a status note, not a migration recommendation.
• Vulnerable configuration: any affected instance where one of /realms/{realm}/protocol/saml, /realms/{realm}/broker/saml/endpoint, or /realms/{realm}/protocol/saml/resolve is reachable by the attacker. Authentication requirements and SAML signature validation do not protect the parser.

Vendor security history

Keycloak has made visible security investments. A fuzzing audit announced on November 19, 2024, funded by CNCF and performed by Ada Logics, added 24 harnesses targeting complex processing routines and interactions with external services. The harnesses are integrated into OSS Fuzz for continuous execution. The audit found a low-severity crash, which the auditors fixed upstream. Nothing in the sources indicates that the audit exercised the SAML time parsing path involved here, and this CVE shows that continuous fuzzing does not catch every algorithmic complexity issue.

The project also publishes a Security Charter. Under it, a Security Response Team triages reports and coordinates with Resolution Teams, which fix, test, and coordinate patches with release and quality engineering. Security fixes are prioritized over other backlog items. Keycloak's security policy notes that, depending on severity, fixes may land in the current or following major.minor release, and points users who cannot upgrade regularly toward Red Hat Build of Keycloak for longer support of specific versions. Red Hat's lifecycle policy delivers qualified Critical and Important security patches through its Full Support and Maintenance Support phases. In this case the upstream fix shipped the same day the CVE was published, while the commercial erratum is still pending.

References

• NVD: CVE-2026-107123
• CVE Record: CVE-2026-107123
• Red Hat Customer Portal: CVE-2026-107123
• Red Hat Bugzilla 2547297
• Keycloak commit 0206529f: Limit the length of dates and durations
• Keycloak commit 0206529f (GitHub API)
• Keycloak issue #54690 (GitHub API)
• Keycloak 26.8.2 release (GitHub API)
• Keycloak Security Advisories on GitHub
• Keycloak Security Policy
• Keycloak Security Charter
• Keycloak Release Notes
• Keycloak 26.8.1 released
• Keycloak 26.7.2 released
• Red Hat build of Keycloak Life Cycle and Support Policies
• CNCF: Keycloak completes fuzzing audit
• CNCF: Keycloak project page
• CNCF: Keycloak joins CNCF as an incubating project
• CISA Known Exploited Vulnerabilities Catalog
• CISA KEV JSON feed
• VulDB: CVE-2026-107123