CVE-2026-47839 in UAA
Summary
by MITRE • 09/11/2026
A vulnerability allows users authenticating through a federated OIDC provider to obtain the uaa.admin scope despite operators restricting that provider through externalGroupsWhitelist configuration. The issue occurs specifically when an OIDC identity provider uses groupMappingMode: AS_SCOPES with a wildcard externalGroupsWhitelist entry.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The described vulnerability represents a critical authorization bypass within Cloud Foundry’s User Account and Authentication (UAA) service, specifically affecting deployments that utilize OpenID Connect for federated authentication. This flaw allows authenticated users to escalate their privileges by acquiring the uaa.admin scope, which grants unrestricted administrative access to the UAA server itself. The root cause lies in a logic error within how the system processes group mappings when specific configuration parameters are combined. When an OIDC identity provider is configured with groupMappingMode set to AS_SCOPES and the externalGroupsWhitelist contains wildcard entries, the validation mechanism fails to properly restrict scope assignment based on the whitelist constraints. This misconfiguration effectively nullifies the intended security boundary, allowing any user authenticated through that specific federated provider to bypass access controls and assume administrative privileges.
From a technical perspective, this vulnerability exploits the interaction between group mapping strategies and whitelisting logic in UAA’s token generation process. In standard operations, external groups from an identity provider are mapped to local scopes or roles based on administrator-defined rules. The AS_SCOPES mode is designed to map incoming user attributes directly into OAuth2 scopes within the issued access tokens. However, when a wildcard pattern is used in the externalGroupsWhitelist configuration alongside this mapping mode, the system incorrectly interprets the scope assignment permissions. Instead of filtering out unauthorized groups or restricting them from being mapped to sensitive administrative scopes like uaa.admin, the logic erroneously permits the derivation of these high-privilege scopes for any authenticated user associated with that provider. This indicates a failure in input validation and access control enforcement during the token issuance phase, where the system trusts the federated identity claims without sufficient verification against the configured security policies.
The operational impact of this vulnerability is severe, as it compromises the integrity and availability of the entire Cloud Foundry platform managed by UAA. An attacker who gains authentication through a vulnerable OIDC provider can obtain administrative credentials for UAA itself. With uaa.admin privileges, an adversary can create new administrator accounts, modify existing user permissions, access sensitive credential stores, and potentially deploy malicious applications or services across all spaces within the Cloud Foundry environment. This effectively results in full system compromise, as UAA serves as the central identity provider for many enterprise cloud deployments. The attacker could exfiltrate data from application instances, disrupt service availability by deleting critical resources, or establish persistent backdoors that survive platform restarts and updates.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where a user is granted privileges they should not possess due to flawed configuration logic. It also relates closely to CWE-862, Missing Authorization, as the system fails to enforce access control policies during scope assignment. In terms of MITRE ATT&CK frameworks, this behavior corresponds to T1078 Valid Accounts and potentially T1098 Authorized Impersonation if an attacker leverages these gained privileges to impersonate other users or services within the platform. The exploitation chain typically involves initial authentication via a compromised or misconfigured federated identity provider followed by privilege escalation through token manipulation, highlighting the importance of strict configuration hygiene in identity management systems.
Mitigation strategies must focus on correcting the UAA configuration and applying immediate patches if available from the vendor. Administrators should audit their externalGroupsWhitelist configurations to ensure that wildcard entries are not used when groupMappingMode is set to AS_SCOPES for providers that might be accessible by untrusted users or where strict access control is required. Replacing wildcards with explicit, granular lists of allowed groups can prevent the unintended scope derivation. Additionally, organizations should implement least-privilege principles across their identity federation setups and regularly review OIDC provider configurations to ensure they align with current security policies. Enabling comprehensive audit logging for UAA token issuance events will help detect any anomalous attempts to acquire administrative scopes. If patching is not immediately feasible, network-level controls such as restricting access to the UAA endpoint from untrusted networks or disabling federation for high-privilege accounts can serve as temporary compensating measures until a permanent fix is deployed.