Bug 2482458 (CVE-2026-9791)
| Summary: | CVE-2026-9791 keycloak-rhel9: Organization Data Leak After Feature Disabled in Keycloak | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | aschwart, aszczucz, boliveir, drichtar, mposolda, pjindal, rmartinc, security-response-team, ssilvert, sthorger, vmuzikar |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in Keycloak. An authenticated user with existing organization membership can exploit this flaw by accessing user-facing APIs, such as the account API or by requesting an OpenID Connect (OIDC) token with the 'organization' scope. This allows organization metadata to be disclosed in tokens, even after an administrator has explicitly disabled the Organizations feature, potentially leading to incorrect authorization decisions by resource servers.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Summary: When organizationsEnabled is set to false at the realm level, Keycloak correctly blocks the admin Organizations API (returning 404), but fails to enforce the disabled state on user-facing paths. The account API (GET /realms/{realm}/account/organizations) continues to return organization membership data, and OIDC token requests with scope=openid organization still issue tokens containing the organization claim. This allows organization metadata to leak into tokens that resource servers may use for authorization decisions, even after an administrator has explicitly disabled the Organizations feature. Requirements to exploit: The attacker must be an authenticated user with existing organization membership. The realm must have had Organizations enabled previously and then disabled by an administrator. The client must be configured to allow the organization scope. The exploit is confirmed for client-credentials and resource-owner-password grant types, and the account API. Component affected: org.keycloak.organization Version affected: Versions with Organizations support (reported via YWH, specific version not stated) Patch available: no CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (4.3 Medium) Embargo: no Acknowledgement: Name: Evan Hendra Affiliation: Independent Security Researcher Email: evanhendra48 Steps to reproduce: 1. Enable Organizations on a realm and create organization memberships for users. 2. As an administrator, disable Organizations by setting organizationsEnabled=false on the realm. 3. As an authenticated user, send GET /realms/{realm}/account/organizations. Observe that organization membership data is returned (200 OK) despite the feature being disabled. 4. Request a token with scope=openid organization using the client-credentials or resource-owner-password grant type. Observe that the issued token contains the organization claim. 5. A resource server relying on the organization claim will continue applying organization-based authorization even though the administrator disabled the feature.