CVE-2024-8698Keycloak SAML signature validation bypass
What broke
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. 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 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, 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 and SAML vs OIDC.
Sources
- NVD: CVE-2024-8698
- Red Hat CVE-2024-8698 / Keycloak issue 33116
Related identity CVEs
Related on Start with Identity
- CVEKeycloak accepts SAML from a disabled identity provider
A remote attacker can complete a broker login with a valid SAML response even after the SAML IdP is disabled in Keycloak. Unauthorized authentication via a cont
- CVEKeycloak SAML broker assertion replay, session hijack
Keycloak's SAML broker accepted a replayed assertion and hijacked a user session. An authentication bypass on the broker edge. Patched in the 2026 Keycloak SAML
- CVEKeycloak SAML POST-binding XSS via ACS URL
The SAML POST-binding flow reflected a crafted Assertion Consumer Service URL as script. An XSS on the IdP login path is session theft. Patched with the April 2
- BlogFortinet's January SSO bypass hit boxes already patched for December's SAML bug
CVE-2026-24858 is the follow-on FortiCloud SSO SAML bypass. Devices patched for CVE-2025-59718 and 59719 were still exploitable. Actively exploited. CISA guidan
- GlossaryIdentity Federation
A trust relationship between identity providers and service providers that lets users authenticate once at their home IdP and access applications at the other p
- GlossaryService Provider (SP)
The application that consumes identity assertions from an IdP to grant the user access. In SAML it's the SP; in OIDC the equivalent is the Relying Party. The se
Technique
This CVE is an instance of Federation trust abuse and SAML forgery. A service provider that accepts a SAML assertion it should have rejected treats a forged identity as authenticated, because the failure sits in signature validation code, not in cryptography.