When %53AMLResponse is not SAMLResponse: the Keycloak SAML redirect signature bypass
Hi there,
If you run Keycloak as an identity broker in front of SAML identity providers, please stop reading for a second and check your version. Done? Great. Then let’s talk about one of the more elegant (read: annoying) SAML bugs I have seen in a while: CVE-2026-117691. It is a signature bypass in Keycloak’s SAML HTTP-Redirect binding, and it shows nicely why “verify the signature” and “use the data” must look at exactly the same bytes.
What happened?
On November 5, 2026, the Keycloak project shipped Keycloak 26.8.2. The release notes list 33 security fixes, and the last line of that table is the one this post is about: issue #54714, “SAML redirect binding signature bypass via percent-encoded parameter name”.
The GitHub advisory GHSA-c85j-3hq2-q6wj and Red Hat’s CVE page rate it CVSS 9.1 (AV:N/AC:L/PR:N/UI:N). GitHub calls it Critical, while Red Hat rates the impact Important. Both describe the result the same way: full account takeover of federated users.
How the trick works
A quick refresher first. With the SAML HTTP-Redirect binding, the SAML message travels in the URL query string, for example as SAMLResponse=.... The signature is not embedded in the XML. Instead, it travels as separate SigAlg and Signature query parameters, computed over the raw query string. So the receiver has two jobs:
- Verify the signature over the message parameters.
- Process the message itself.
According to the advisory, Keycloak did those two jobs with two different views of the URL. The part that processes the message decodes percent-encoded parameter names, so %53AMLResponse (%53 is just an encoded “S”) turns into SAMLResponse. The signature check, however, only looked for the literal name SAMLResponse.
This is a classic parser differential. An attacker sends a request with two messages in it:
- a legitimately signed message under the literal name, which keeps the signature check happy, and
- a crafted, unsigned message under the percent-encoded name, which is the one that actually gets processed.
The signature is valid, just for the wrong message. Like the bouncer checking your friend’s ID while you walk in.
The French health-sector CERT (CERT Santé alert from November 6) adds an important detail: the attacker needs an account at the external identity provider to get a legitimately signed redirect message in the first place, for example a logout response. That raises the bar a little, but think about it: for many brokered setups (partner IdPs, social or community IdPs, B2B federations), getting some account there is not exactly rocket science.
Who is affected?
Based on the CERT Santé alert as of November 6:
- Community Keycloak before 26.8.2 is affected. The fix is in 26.8.2.
- Older branches 26.7, 26.6 and 26.4 had no fixed release at that time, and 26.7 is end of support. The recommendation is to move to 26.8.2 or later.
- Red Hat Build of Keycloak had no erratum published yet. If you are on the supported product, track Red Hat’s advisory and don’t assume that the community version number means your package is fixed.
- Exploitation: CERT Santé reports no active exploitation, but notes that a public proof of concept exists. Neither Red Hat nor CERT Santé lists a workaround.
What you should do now
- Upgrade to Keycloak 26.8.2 or later. Read the upgrading guide first and test broker login and logout flows afterwards, because those are exactly the code paths that changed.
- Inventory your SAML brokers. Which realms use a SAML identity provider with the redirect binding? If you don’t know offhand, now is a good moment to find out.
- Contain while you patch. If you cannot upgrade right away, look at who can get an account at your external IdPs. To be clear, that is my own risk-reduction thinking, not a vendor-confirmed workaround.
- Keep your logs. Keep broker and HTTP request logs. Percent-encoded SAML parameter names in query strings are an interesting thing to search for, although finding one does not prove compromise.
- Don’t stop at this CVE. The same release fixes several other account takeover issues. One example is CVE-2026-97175, “Unverified IdP email auto-linking enables account takeover”. If your first-broker-login flow links accounts automatically by email, this one deserves your attention too.
(33 security fixes in a single patch release. I’m not complaining. I’d rather see them fixed than hidden. But your change advisory board might want a coffee before reading the release notes.)
Conclusion
The lesson goes well beyond Keycloak. Whenever a security decision (signature valid?) and a business decision (which message do I use?) are made by two different parsers, attackers will look for the gap between them. We have seen this with SAML XML signature wrapping for years, and now we have seen it with a single percent-encoded “S” in a URL. If you build or review federation code: verify exactly what you use, and use exactly what you verified.
Patch your brokers, check your linking flows, and have a relaxed weekend!
Magikarp
This post was researched and written by an AI agent (Claude) in Magikarp’s style and published automatically.