Brief Summary: Keycloak CVE-2026-117691, SAML HTTP Redirect Signature Bypass via Percent-Encoded Parameter Names

Introduction

A signature verification bypass in Keycloak's SAML HTTP Redirect binding can let an attacker substitute an unsigned, attacker-controlled SAML message for a legitimately signed one, resulting in full account takeover of federated users. For organizations that broker external identity providers through Red Hat build of Keycloak, a valid signature on the wire no longer guarantees that the server is acting on the response that was actually authenticated.

Keycloak is an open source identity and access management project, now a CNCF incubating project, used in production by organizations including Accenture, CERN, Cisco, Hitachi, and Okta. Red Hat build of Keycloak is the commercial offering based on that community project. This CVE concerns the commercial product specifically, which matters when scoping exposure.

Technical information

The affected component is keycloak-services, and the underlying weakness is CWE-347, Improper Verification of Cryptographic Signature. The vendor description scopes the issue to the SAML HTTP Redirect binding. It is not a general failure of every Keycloak authentication protocol.

Root cause: two views of the same parameter

Two code paths that handle the same inbound request disagree about which parameter is which.

In the SAML HTTP Redirect binding, the relevant parameters (SAMLResponse, and signature-related parameters) are carried in the query string. Keycloak has two consumers of that query string, and they interpret parameter names differently:

• The request processing path decodes query parameter names. Under this path, a percent-encoded name such as %53AMLResponse (where %53 is the ASCII code for the letter S) is decoded to SAMLResponse. The research also describes SAML%52esponse collapsing to SAMLResponse in the same way. The server therefore treats the attacker's crafted parameter as the SAML response it should process.
• The signature reconstruction path reads query parameters with decoding disabled, and the signature verification logic checks the literal parameter name. Under this path, the percent-encoded name and the literal name are distinct strings.

Because of this mismatch, one SAML document can supply the identity that the server actually processes, while a different SAML document supplies the valid signature that passes verification. The verified input and the consumed input are not the same object.

The advisory describes a signature verification bypass. It does not describe recovery of an identity provider's signing key or a demonstrated break of the signing algorithm. The signature is genuine. It authenticates a different message from the one that drives the authentication decision.

Verified technical attributes

The sources carry two severity labels. The numerical CVSS classification is Critical, while Red Hat's product impact rating is Important. These are separate assessments and should not be conflated.

Attack flow

The following sequence is drawn from the vendor description and the closely related Abraxas Labs laboratory case. The lab reproduced the mechanism on stock Keycloak 26.8.1 with a SAML broker configured with validateSignature=true and wantAssertionsSigned absent or false.

1. The attacker obtains a victim's NameID and a genuine, signed HTTP Redirect response from the identity provider. These prerequisites come from the research case. The official CVE description does not specify them independently.
2. The attacker constructs a request that carries two representations of the SAML response parameter: a literal SAMLResponse whose value and signature are the genuine signed material, and a percent-encoded variant (for example %53AMLResponse) carrying the crafted, unsigned content set to the victim identity.
3. The signature reconstruction path reads the literal parameter name with decoding disabled and validates the signature successfully, because that material is genuinely signed.
4. The request processing path decodes the parameter names, collapsing the encoded variant onto SAMLResponse, and consumes the attacker-controlled content as the authenticated identity.
5. The outcome, per the vendor, is full account takeover of the federated user.

In the lab's controlled test, the honest control request completed as the attacker identity, while the modified request completed as the victim identity, with the victim account count moving from 0 to 1. The report carefully separates this demonstrated account creation outcome from its inferred impact on existing brokered accounts. The official CVE states full account takeover. The lab result is narrower evidence of the parsing failure. We treat the lab findings as related evidence of the mechanism, not as a confirmed exploit attributed to this CVE. The Abraxas report itself carries no assigned CVE.

Affected systems and versions

The structured CVE record provides default affected status rather than explicit version boundaries, so the available data does not establish an exact earliest vulnerable release or a first fixed release.

• Affected: Red Hat build of Keycloak, packages keycloak-services and rhbk/keycloak-rhel9, each marked affected by default.
• Explicitly unaffected: Red Hat Single Sign-On 7, package keycloak-services.

The related Abraxas Labs case was reproduced on stock Keycloak 26.8.1. That release should not be presented as a verified remedy for the described query name discrepancy, and the lab report does not provide an official affected version range for this CVE. The retrieved CVE records identify no fixed release, and Red Hat states that mitigation is either unavailable or does not meet its criteria for ease of deployment, broad applicability, or stability.

Sourced hardening considerations

The available sources support a few qualified hardening measures. None of them is a confirmed vendor fix.

• Enable Want Assertions Signed for relevant SAML brokers. The Abraxas Labs research recommends wantAssertionsSigned, and upstream Keycloak documentation describes this setting as expecting signed assertions from the external identity provider. It requires the identity provider to supply signed assertions, and it is hardening supported by related research, not a Red Hat confirmed CVE workaround. The lab case succeeds precisely because transport signature validation authenticates a different response from the one consumed, while the configuration does not require assertion signatures.
• Validate Signature with trusted validation certificates. Keycloak documentation describes expecting signed SAML messages and validating them with the identity provider's certificate, obtained from metadata or configured as a validating X509 certificate. The related lab succeeds with validateSignature=true, so this setting alone does not address the demonstrated discrepancy.
• Consistent parsing and signature reconstruction. The research proposes decoding parameter names consistently, or rejecting requests that contain more than one decoded SAMLResponse. These are proposed implementation corrections, not evidence that a released vendor patch exists.

Preferring HTTP POST is not a demonstrated remedy. The research notes that the GET assertion consumer endpoint remains mounted even when the identity provider prefers POST, although a POST-only identity provider does not supply the signed Redirect required by that particular attack.

Vendor security history

Keycloak maintains a Security Response Team and Resolution Teams, with a charter describing triage, CVE assignment, private fixes, review, testing, release, and official advisories. On the positive side, an external Cure53 penetration test in fall 2019, funded by REWE Digital GmbH, described Keycloak as mature and solid with generally limited risks and stable core security aspects, while acknowledging that project size and complexity prevent ruling out all issues.

CVE-2024-8698 is a relevant counterexample. In that separate issue, XMLSignatureUtil determined signature coverage from the signature's position in the XML document rather than from the Reference element, allowing crafted responses to bypass verification and potentially enable privilege escalation or impersonation. That issue is closed, links a merged fix, and identifies release targets 25.0.6 and 26.0.0.

The two issues differ technically. CVE-2024-8698 concerns XML signature coverage, while CVE-2026-117691 concerns query name interpretation. What they share is that a signature can be valid while the application derives identity from content that the relevant check did not authenticate. This comparison is our analysis of the two documented mechanisms, not evidence that they share a patch or exploit.

References

• NVD: CVE-2026-117691
• CVE.org Record: CVE-2026-117691
• Red Hat Customer Portal: CVE-2026-117691
• Red Hat Bugzilla 2561977
• MITRE CVE Services record for CVE-2026-117691
• NVD REST API entry for CVE-2026-117691
• Abraxas Labs: Keycloak 26.8.1, SAML redirect query-name split
• OffSeq Threat Radar entry for CVE-2026-117691
• Keycloak SAML identity broker documentation (saml.adoc)
• Red Hat build of Keycloak Life Cycle and Support Policies
• Red Hat build of Keycloak product page
• Keycloak GitHub Issue 33116 (CVE-2024-8698)
• Red Hat Customer Portal: CVE-2024-8698
• Keycloak Security Policy
• Keycloak Security Charter
• Keycloak on CNCF