Keycloak's SAML signature check can be bypassed by encoded parameter names
SAML HTTP-Redirect binding gives an identity provider a compact way to send a signed authentication response. The browser carries the signed fields in a URL query string. CVE-2026-117691 shows what happens when the code that verifies parameter names and the code that later processes them disagree about percent encoding.
Red Hat describes a signature bypass in Keycloak's SAML HTTP-Redirect binding. A crafted GET request can place a percent-encoded unsigned SAML parameter before a legitimately signed parameter. The verification path checks the literal parameter name, while the request-processing path decodes the name. The signed request remains valid, but the application can act on a different parameter set from the one the signature appeared to cover.
The flaw affects a specific integration pattern. The Keycloak instance must use SAML HTTP-Redirect binding for federated identity. It is not a claim that every Keycloak login or every SAML deployment is exploitable. It is a claim that signature verification must be tied to the same parsed representation that authorization and session creation use.
Why a valid signature is not enough
A SAML signature is a statement about a canonical representation of a message. If the verifier signs or checks one representation and the business logic consumes another, the signature stops describing the accepted request. Percent-encoded parameter names make the gap visible because SAMLRequest and %53AMLRequest can be treated differently by a raw-name check and a decoder.
The security question is not whether Keycloak can verify a legitimate identity provider response. It can. The question is whether an attacker can obtain a signed response and then alter which unsigned parameter becomes authoritative after parsing. Red Hat's mitigation note says the concern applies where attackers can capture legitimately signed redirect-binding messages, so registration and trust boundaries around external identity providers matter.
This is a confused-deputy pattern inside an authentication protocol. Keycloak is expected to protect the relying application from forged identity assertions. When verification and processing use different views of the request, an attacker may influence the authentication result without breaking the cryptography.
What operators should check
First identify SAML identity providers configured with HTTP-Redirect binding. Inventory the trust relationships, the registration policy for external identity providers, and the attributes that can influence user creation or account linking. A federated provider that anyone can register is a different risk from a tightly controlled enterprise provider, even if both use the same binding.
Review the fixed builds published by Red Hat and the Keycloak project. Do not assume that a package with the same major version is patched because the management console shows a recent release date. The relevant build must include the parser-alignment fix. Container images, reverse-proxy deployments, and managed identity services need separate confirmation.
Retain request logs that include the raw query string where policy permits, along with the normalized values used by the application. Avoid logging complete SAML assertions or personal data. The useful evidence is the parameter-name sequence, the signature verification result, the identity provider identifier, and the account or session outcome.
Detection and containment
Search for duplicate or encoded SAML parameter names in the same request. Look for requests where one parameter is signed and another has the same decoded name but a different raw spelling. Correlate those requests with unusual account creation, identity linking, role changes, or sessions from an external identity provider.
Until the fix is deployed, restrict registration of external identity providers and narrow which providers can use HTTP-Redirect binding. Network controls alone do not repair a signed-message parsing flaw, but they can reduce the number of parties able to capture or replay a legitimate response. Increase review of changes to SAML mappers, authentication flows, and identity-provider trust settings.
After upgrading, run a negative test against a staging identity provider. Submit a signed redirect with a harmless encoded parameter-name variation and confirm that Keycloak rejects it before any authentication session is created. A successful login with the normal provider is necessary but not sufficient.
The broader design rule is straightforward: signature verification, parameter parsing, and authorization must operate on one immutable representation. If a framework decodes the query string more than once, every security decision should use the decoded result, or the request should fail closed. Keycloak's advisory makes that rule concrete for SAML redirect bindings.
Top comments (0)