The vulnerability allows a low-privileged user to gain administrator-level privileges. This is due to improper validation of the role claim within JWTs processed by the Token Exchange module. The analysis of the security patches, specifically commit 1a7010ffa027932a72d78f0a876ecf1cfa1c8488, reveals the root cause.
The core of the issue lies in the IdentityResolutionService class, located in packages/cli/src/modules/token-exchange/services/identity-resolution.service.ts. Two methods in this class, resolveRoleForNewUser and resolveRoleForExistingUser, were identified as vulnerable.
-
IdentityResolutionService.resolveRoleForNewUser: This was the most critical vulnerable function. When a new user was provisioned via token exchange (a process known as JIT provisioning), this function was called to determine the user's role based on the JWT. Before the fix, if the role claim contained a role that wasn't a known built-in role, the function would not throw an error. Instead, it would proceed to create the user with this unvalidated role. The application's downstream logic then incorrectly defaulted to granting this new user the maximum possible permissions, described in the advisory as "all Public API key scopes". The patch rectifies this by adding a database check to ensure the role exists (this.roleService.isGlobalRole) and is licensed (this.roleService.isRoleLicensed), throwing an error if not.
-
IdentityResolutionService.resolveRoleForExistingUser: This function handles role updates for existing users. While it was less critical because it ignored completely unknown roles, it still contained a flaw. It failed to check if a claimed custom role was licensed for the instance. This created a loophole where an existing user could be escalated to a privileged custom role they shouldn't have access to. The patch adds the same license check as in the new user function, closing this privilege escalation path.
During an exploit, these functions would be invoked as part of the authentication flow when the /rest/auth/oauth/token or /rest/auth/embed endpoints are called with a specially crafted JWT. A runtime profiler would show these methods in the stack trace during the processing of the malicious token exchange request.