# Keycloak SAML signature validation bypass

Source: https://startwithidentity.com/cves/cve-2024-8698/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

[Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/)'s `XMLSignatureUtil` SAML signature check returned the wrong answer. A crafted response could bypass validation, impersonate a user, and escalate privilege in any realm that accepted [SAML](https://startwithidentity.com/glossary/saml/). Red Hat rated it high and patched in September 2024 (RHSA train around RHSA-2024 and the Keycloak 25.x / 24.x fixes).

## Why it matters

Keycloak is the default on-prem [IdP](https://startwithidentity.com/glossary/identity-provider/) for a lot of Kubernetes and Red Hat estates. A SAML verifier bug there is every federated app, not one SP. 2024 was the year ruby-saml, GHES, samlify, and Keycloak all failed the same signature-binding test.

## What to do

- Upgrade Keycloak off the September 2024 advisory. Confirm the running image, not the Helm chart default.
- If the realm used SAML while unpatched, review first-time NameIDs and new realm-admin role mappings.
- Pair with the 2025 Keycloak set ([First Broker Login](https://startwithidentity.com/cves/cve-2025-7365/), password-reset AD skip) so you do not patch SAML and leave the other identity holes.

## After you patch

A SAML bypass means the service provider accepted an assertion it should have rejected, so anyone who exploited it authenticated as a real user and left a normal-looking log line.

- **Revoke every session** issued by the affected service provider, then rotate its session signing keys. Patching stops new forgeries and does nothing about sessions already minted.
- **Audit administrative accounts and group memberships** for changes during the exposure window. Signing in as an administrator is the point of this class, and adding a second account is the standard persistence step.
- **Rotate the identity provider signing certificate** if the flaw involved signature validation, and confirm the service provider pins the expected certificate rather than trusting anything in the assertion.
- **Check your own implementation for the same class**: exact-match comparison on verification results, rejection of unexpected signature algorithms, and audience and recency checks on every assertion. See [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/).

## Sources

- [NVD: CVE-2024-8698](https://nvd.nist.gov/vuln/detail/CVE-2024-8698)
- Red Hat CVE-2024-8698 / Keycloak issue 33116