CVE-2026-3047 in Keycloak
Summary
by MITRE • 03/05/2026
A flaw was found in org.keycloak.broker.saml. When a disabled Security Assertion Markup Language (SAML) client is configured as an Identity Provider (IdP)-initiated broker landing target, it can still complete the login process and establish a Single Sign-On (SSO) session. This allows a remote attacker to gain unauthorized access to other enabled clients without re-authentication, effectively bypassing security restrictions.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/26/2026
This vulnerability resides within the keycloak authentication system specifically in the saml broker component identified as org.keycloak.broker.saml. The flaw represents a critical authorization bypass issue that fundamentally undermines the security model of identity federation within the Keycloak platform. When a SAML client is disabled within the system configuration, the normal expectation is that this client should be inaccessible to authentication requests and should not be able to participate in the SSO session establishment process. However, this vulnerability demonstrates that disabled clients can still function as landing targets for IdP-initiated authentication flows, creating an unexpected pathway for unauthorized access.
The technical mechanism behind this vulnerability involves the improper handling of disabled client states during SAML authentication flows. When an Identity Provider initiates an authentication request to a Keycloak broker, the system should validate that the target client is enabled and active before proceeding with session establishment. The flaw occurs because the system fails to properly enforce the disabled client status during the IdP-initiated broker landing process, allowing authentication to proceed even when the client configuration explicitly indicates it should be inactive. This represents a classic case of inadequate access control validation where the system does not properly check the client's enabled status before completing the authentication flow.
The operational impact of this vulnerability is severe and far-reaching within enterprise environments that rely on Keycloak for identity management and federation. An attacker who can identify disabled SAML clients configured as broker targets can exploit this weakness to establish SSO sessions that grant access to other enabled clients within the same realm without requiring additional authentication. This creates a privilege escalation scenario where the attacker can move laterally across the authentication domain, potentially gaining access to sensitive applications and data that should be protected by the disabled client's intended restrictions. The vulnerability effectively transforms disabled security controls into active attack vectors, undermining the principle of least privilege and creating persistent access opportunities.
This vulnerability aligns with CWE-668 (Exposure of Resource to Wrong Sphere) and CWE-284 (Improper Access Control) while mapping to ATT&CK technique T1078.004 (Valid Accounts: Cloud Accounts) and T1531 (Account Access Removal). The flaw demonstrates how improper state validation can create unintended access paths within authentication systems, particularly in federated environments where trust relationships between identity providers and service providers can be exploited. Organizations using Keycloak for SAML-based identity federation are particularly at risk since this vulnerability can be exploited remotely without requiring privileged access to the Keycloak server itself, making it a significant concern for cloud-based and distributed authentication environments.
Mitigation strategies should focus on immediate configuration reviews and implementation of additional access control measures. Organizations must ensure that all disabled SAML clients are properly removed from broker configurations or that explicit access controls are implemented to prevent IdP-initiated authentication flows from targeting disabled clients. The recommended approach includes implementing additional validation checks during the authentication flow to verify client status before session establishment, as well as regular audits of broker configurations to identify and remediate similar issues. System administrators should also consider implementing monitoring for unusual authentication patterns that might indicate exploitation attempts, particularly around disabled client access attempts. Patch management procedures should be prioritized to ensure timely deployment of vendor-provided fixes, while network segmentation and additional authentication layers can provide defense-in-depth protection against potential exploitation attempts.