CVE-2026-3009: 
Java vulnerability analysis and mitigation

CVE-2026-3009 is an improper authorization vulnerability in the IdentityBrokerService.performLogin endpoint of Keycloak (the org.keycloak/keycloak-services component) that allows authentication to proceed through a disabled Identity Provider (IdP). Disclosed on March 5, 2026, the flaw affects Red Hat build of Keycloak 26.4 and 26.4.10, Red Hat Single Sign-On 7.0, JBoss Enterprise Application Platform 8.0, and the JBoss EAP Expansion Pack. It carries a CVSS v3.1 base score of 8.1 (High) (Red Hat CVE, Red Hat Bugzilla).

The root cause is improper authorization (CWE-285 / CWE-863): the broker login endpoint (/realms/{realm}/broker/{alias}/login) does not re-validate the enabled/disabled status of the configured IdP at the time of login processing. If a valid authentication flow was initiated before the IdP was administratively disabled, an attacker who knows the IdP alias can manually invoke the broker login URL with valid session parameters, causing the authentication flow to proceed and redirect the user to the external provider despite the IdP being disabled. Exploitation requires no privileges but does require user interaction and knowledge of the IdP alias, making it a network-accessible, low-complexity attack (Red Hat Bugzilla, Red Hat CVE).

Successful exploitation allows an attacker to bypass administrative access controls and authenticate through a disabled external Identity Provider, undermining the integrity of the access control enforcement model. This results in high confidentiality and integrity impact — unauthorized users may gain access to protected resources and data that administrators intended to restrict by disabling the IdP. Availability is not directly impacted (Red Hat CVE, Red Hat Bugzilla).

1. Reconnaissance: Identify a Keycloak instance running an affected version (Red Hat build of Keycloak 26.4.x, JBOSS EAP 8.0, or Red Hat SSO 7.0) and enumerate configured Identity Provider aliases, which may be discoverable via the Keycloak admin console, public realm endpoints, or social engineering.
2. Initiate a legitimate login flow: Before or after the IdP is disabled, initiate a valid authentication flow through the target IdP to obtain a valid session token and flow parameters.
3. Invoke the broker login endpoint: Manually craft and send a request to /realms/{realm}/broker/{alias}/login using the known IdP alias and the previously captured valid session parameters, even after the IdP has been administratively disabled.
4. Bypass access control: Because the endpoint does not re-validate the IdP's enabled/disabled status, the authentication flow proceeds and redirects to the external provider, completing authentication as if the IdP were still active.
5. Gain unauthorized access: The attacker authenticates via the disabled IdP and obtains a valid Keycloak session, potentially accessing protected applications and resources (Red Hat Bugzilla, Red Hat CVE).

• Logs: Keycloak server logs showing successful authentication events via an IdP alias that has been administratively disabled; look for IdentityBrokerService log entries referencing a disabled provider alias after the disable action was recorded.
• Logs: Admin audit logs showing an IdP being disabled, followed shortly by authentication events referencing that same IdP alias.
• Network: HTTP requests to /realms/{realm}/broker/{alias}/login with valid session parameters originating from unexpected or external IP addresses after the IdP was disabled.
• Application: Unexpected active user sessions in the Keycloak admin console associated with accounts that should no longer be able to authenticate via the disabled IdP.

Red Hat has released patches addressing this vulnerability in security advisories RHSA-2026:3947 (standalone packages) and RHSA-2026:3948 (OpenShift container images), both targeting Red Hat build of Keycloak 26.4.10 (RHSA-2026:3947, RHSA-2026:3948). Organizations should upgrade to the patched version (26.4-12 or 26.4.10-1 per ENISA product versioning) immediately. As a temporary workaround, administrators should review all configured Identity Providers and remove or fully delete (rather than just disable) any external providers that should not be used, and monitor authentication logs for unexpected IdP usage.

The vulnerability was noted in the Java community news roundup for early March 2026, indicating awareness among Java/middleware developers (InfoQ). A Bluesky post from a cybersecurity blog also highlighted the CVE shortly after disclosure. Overall community reaction has been measured, consistent with a High-severity but non-critical (no RCE, no public PoC) authentication bypass in an enterprise identity product.