SAML single sign-on is supposed to be the part of your architecture you don't have to think about. The Identity Provider asserts who you are, the Service Provider trusts the signature, and everyone moves on. CVE-2026-117691 is a reminder that "trusts the signature" is doing a lot of work in that sentence.

The vulnerability sits in how Keycloak validates the digital signatures attached to SAML assertions. Under the right conditions, an attacker who can intercept or manipulate the SAML flow can submit a crafted response that passes validation even though it shouldn't — a signature bypass, not a stolen key.

What the flaw actually is

SAML assertions are XML documents. The signature is supposed to prove the assertion came from the expected Identity Provider and wasn't altered in transit. Validation normally means: check the signature against the issuer's public key, and confirm the signed content matches what you received.

CVE-2026-117691 is an implementation flaw in that validation path. By manipulating how the XML is structured — namespace declarations, element ordering, attributes that aren't fully accounted for during canonicalization — an attacker can craft a document where the signature mathematically validates against the expected key but the security check it was supposed to enforce is bypassed.

That distinction matters. This is not a case of a missing signature that a lazy implementation accepted. The signature is present and valid; the problem is that the code path trusted a structure it shouldn't have.

Why the impact is severe

If an attacker can forge a SAML assertion:

  • Privilege escalation — assume the identity of an administrator without credentials.
  • Session hijacking — forge assertions that grant persistent access to connected applications.
  • Data exfiltration — reach protected resources behind the SSO layer.

For any organisation running Keycloak as its Identity Provider, this is a direct path around the front door.

Patching

The fix is a Keycloak upgrade. Identify the minimum version that addresses CVE-2026-117691 from the vendor advisory and target it.

Containerised deployment:

docker pull keycloak:<patched-version> docker stop keycloak_container docker rm keycloak_container docker run -d \ --name keycloak_container \ -p 8080:8080 \ -v /path/to/keycloak/data:/opt/keycloak/data \ keycloak:<patched-version> \ start-dev

Validate your volume mapping before restarting — realms, clients, and user data should survive the swap.

If you can't patch immediately

  • Restrict the SAML endpoint. Allow only known Identity Provider IP addresses to reach /auth/realms/*/protocol/saml/* at the firewall or load balancer, and rate-limit the endpoint.
  • Audit custom extensions and themes. Anything that hasn't been updated in the last year should be treated as a risk until verified against the patched version.
  • Pin certificates. Use the expected signing certificates for every connected IdP, and confirm the SP entity ID matches exactly what Keycloak expects.

Hardening that lasts

  • Enforce strong SAML metadata validation on every IdP connection.
  • Minimise the scopes and attributes you request from the IdP — if an attribute isn't needed, don't ask for it.
  • Use granular realm role mapping instead of broad group assertions.
  • Schedule quarterly penetration tests against authentication flows, not just the application layer.

The general lesson: XML signature validation is subtle, and canonicalisation bugs are a recurring class. Treat the identity layer as a critical asset with its own patch cycle, monitoring, and test coverage.

This is an expanded technical note based on our breakdown of CVE-2026-117691. The original, with vendor references, is here: https://hsecurities.in/blog/keycloak-cve-2026-117691-saml-signature-bypass