CVE-2026-2603Keycloak accepts SAML from a disabled identity provider

What broke

Keycloak still accepted a valid SAML response from an external IdP after an administrator disabled that SAML identity provider. A remote attacker who can present a previously valid (or still-signable) assertion completes a broker login. High. Red Hat / Keycloak patched. CVE-2026-3047 is a related disabled-client landing-target issue on IdP-initiated broker flows.

Why it matters

"Disabled" is how you contain a compromised or decommissioned partner IdP. If the ACS still honors the old signature, disable is theater. Same class as First Broker Login and the 2024 Keycloak SAML signature bug: broker edges keep failing closed.

What to do

• Upgrade Keycloak. After the upgrade, disable is not enough: remove the IdP or rotate its signing key.
• Hunt broker logins whose IdP alias is marked disabled.
• Read the SAML protocol page before you brief this as a one-off.

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-2026-2603
• GitHub GHSA-x4p7-7chp-64hq