Server: Budibase: SSO OAuth2 Token Leakage via User Metadata Endpoints to Power-Role Users (CVE-2026-73304)
## Summary The `/api/users/metadata` and `/api/users/metadata/:id` endpoints in `@budibase/server` return full global user profiles to any user with POWER role or above. For SSO-authenticated users (OIDC, Google), the response includes `oauth2.accessToken` and `oauth2.refreshToken` fields, leaking identity provider credentials to other users who should not have access to them. ## Details When a user authenticates via SSO (OIDC or Google), the OAuth2 tokens are stored in the global CouchDB user document at `packages/backend-core/src/auth/auth.ts:170-173`: ```typescript dbUser.oauth2 = { ...dbUser.oauth2, ...details, } await db.put(dbUser) ``` The user metadata endpoints are protected by `PermissionType.USER, PermissionLevel.READ` (`packages/server/src/api/routes/user.ts:11`), which maps to the POWER permission set (`packages/backend-core/src/security/permissions.ts:99`). **Path 1 — List all users** (`GET /api/users/metadata`): 1. `controller.fetchMetadata` → `sdk.users.fetchMetadata()` (`packages/server/src/sdk/users/utils.ts:78`) 2. → `getGlobalUsers()` → `getRawGlobalUsers()` (`packages/server/src/utilities/global.ts:101-122`) — strips only `password` and `forceResetPassword` 3. → `processUser()` (`packages/server/src/utilities/global.ts:15-76`) — strips only `password` and `roles` 4. The `oauth2` field containing `accessToken` and `refreshToken` is **never removed** **Path 2 — Single user** (`GET /api/users/metadata/:id`): 1. `controller.findMetadata` → `getFullUser()` (`packages/server/src/utilities/users.ts:6`) 2. → `getGlobalUser()` → `getRawGlobalUser()` (`packages/server/src/utilities/global.ts:90-92`) — raw CouchDB fetch, **no field stripping at all** 3. → `processUser()` — strips only `password` and `roles` 4. Same result: `oauth2` tokens are returned There is no output sanitization middleware on these routes that would strip sensitive fields before the response reaches the client. ## PoC **Prerequisites:** A Budibase instance with at least one SSO-authenticated user (OIDC or Google) and a separate user with POWER role in an app. **Step 1 — As the POWER user, list all users:** ```bash curl -s -X GET 'http://localhost:10000/api/users/metadata' \ -H 'Cookie: budibase:auth=<power-user-jwt>' \ -H 'x-budibase-app-id: app_<appid>' | jq '.[].oauth2' ``` **Expected output:** `null` for all users (tokens should not be exposed) **Actual output:** For SSO users, the response includes: ```json { "accessToken": "ya29.a0ARrdaM...", "refreshToken": "1//0eXxXxXxXx..." } ``` **Step 2 — Fetch a specific SSO user's profile:** ```bash curl -s -X GET 'http://localhost:10000/api/users/metadata/ro_ta_users_us_<sso-user-id>' \ -H 'Cookie: budibase:auth=<power-user-jwt>' \ -H 'x-budibase-app-id: app_<appid>' | jq '.oauth2' ``` This also returns the full OAuth2 tokens. ## Impact - A user with POWER role in any app can read **all SSO users' OAuth2 access tokens and refresh tokens** via the list endpoint, without needing to know individual user IDs. - Stolen access tokens can be used to access external identity provider resources (Google Workspace, Azure AD, Okta-protected services) as the victim user. - Refresh tokens allow indefinite token renewal, persisting access even after the original access token expires. - Additionally, `admin`, `builder`, `tenantId`, `ssoId`, and `userGroups` fields are leaked, revealing the full authorization topology of the instance. ## Recommended Fix Strip sensitive SSO fields in `processUser()` at `packages/server/src/utilities/global.ts:15`: ```typescript export async function processUser( user: ContextUser, opts: { appId?: string; groups?: UserGroup[] } = {} ) { if (!user || (!user.roles && !user.userGroups)) { return user } user = cloneDeep(user) delete user.password + delete (user as any).oauth2 + delete (user as any).provider + delete (user as any).providerType + delete (user as any).thirdPartyProfile + delete (user as any).profile + delete (user as any).ssoId + delete (user as any).forceResetPassword // ... rest of function ``` Additionally, `getRawGlobalUsers()` at line 101 should also strip `oauth2` alongside its existing `password`/`forceResetPassword` stripping for defense in depth.
AI Analysis
Technical Summary
The vulnerability in @budibase/server affects versions before 3.39.25. The `/api/users/metadata` and `/api/users/metadata/:id` endpoints return full global user profiles to users with POWER role or above. For users authenticated via SSO (OIDC, Google), the OAuth2 tokens (`accessToken` and `refreshToken`) are stored in the global CouchDB user document but are not stripped from the API responses. The endpoints only remove `password` and `roles` fields but leave the `oauth2` field intact. This results in leakage of sensitive OAuth2 tokens to unauthorized users with POWER role, enabling potential misuse of identity provider credentials. The recommended fix involves explicitly deleting the `oauth2` and other SSO-related sensitive fields in the user processing function and adding defense-in-depth stripping in the raw user fetch function.
Potential Impact
Users with POWER role in any Budibase app can access all SSO users' OAuth2 access and refresh tokens via the user metadata endpoints. This exposure allows unauthorized access to external identity provider resources (e.g., Google Workspace, Azure AD, Okta) as the victim user. Refresh tokens enable indefinite renewal of access, extending the window of compromise. Additionally, leakage of admin, builder, tenantId, ssoId, and userGroups fields reveals the full authorization topology of the instance, potentially aiding further attacks.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The recommended fix is to modify the `processUser()` function to delete the `oauth2` and other SSO-related sensitive fields before returning user metadata. Additionally, the `getRawGlobalUsers()` function should also strip the `oauth2` field for defense in depth. Until a patch is available, restrict POWER role assignments to trusted users only and monitor for suspicious access patterns to user metadata endpoints.
Server: Budibase: SSO OAuth2 Token Leakage via User Metadata Endpoints to Power-Role Users (CVE-2026-73304)
Description
## Summary The `/api/users/metadata` and `/api/users/metadata/:id` endpoints in `@budibase/server` return full global user profiles to any user with POWER role or above. For SSO-authenticated users (OIDC, Google), the response includes `oauth2.accessToken` and `oauth2.refreshToken` fields, leaking identity provider credentials to other users who should not have access to them. ## Details When a user authenticates via SSO (OIDC or Google), the OAuth2 tokens are stored in the global CouchDB user document at `packages/backend-core/src/auth/auth.ts:170-173`: ```typescript dbUser.oauth2 = { ...dbUser.oauth2, ...details, } await db.put(dbUser) ``` The user metadata endpoints are protected by `PermissionType.USER, PermissionLevel.READ` (`packages/server/src/api/routes/user.ts:11`), which maps to the POWER permission set (`packages/backend-core/src/security/permissions.ts:99`). **Path 1 — List all users** (`GET /api/users/metadata`): 1. `controller.fetchMetadata` → `sdk.users.fetchMetadata()` (`packages/server/src/sdk/users/utils.ts:78`) 2. → `getGlobalUsers()` → `getRawGlobalUsers()` (`packages/server/src/utilities/global.ts:101-122`) — strips only `password` and `forceResetPassword` 3. → `processUser()` (`packages/server/src/utilities/global.ts:15-76`) — strips only `password` and `roles` 4. The `oauth2` field containing `accessToken` and `refreshToken` is **never removed** **Path 2 — Single user** (`GET /api/users/metadata/:id`): 1. `controller.findMetadata` → `getFullUser()` (`packages/server/src/utilities/users.ts:6`) 2. → `getGlobalUser()` → `getRawGlobalUser()` (`packages/server/src/utilities/global.ts:90-92`) — raw CouchDB fetch, **no field stripping at all** 3. → `processUser()` — strips only `password` and `roles` 4. Same result: `oauth2` tokens are returned There is no output sanitization middleware on these routes that would strip sensitive fields before the response reaches the client. ## PoC **Prerequisites:** A Budibase instance with at least one SSO-authenticated user (OIDC or Google) and a separate user with POWER role in an app. **Step 1 — As the POWER user, list all users:** ```bash curl -s -X GET 'http://localhost:10000/api/users/metadata' \ -H 'Cookie: budibase:auth=<power-user-jwt>' \ -H 'x-budibase-app-id: app_<appid>' | jq '.[].oauth2' ``` **Expected output:** `null` for all users (tokens should not be exposed) **Actual output:** For SSO users, the response includes: ```json { "accessToken": "ya29.a0ARrdaM...", "refreshToken": "1//0eXxXxXxXx..." } ``` **Step 2 — Fetch a specific SSO user's profile:** ```bash curl -s -X GET 'http://localhost:10000/api/users/metadata/ro_ta_users_us_<sso-user-id>' \ -H 'Cookie: budibase:auth=<power-user-jwt>' \ -H 'x-budibase-app-id: app_<appid>' | jq '.oauth2' ``` This also returns the full OAuth2 tokens. ## Impact - A user with POWER role in any app can read **all SSO users' OAuth2 access tokens and refresh tokens** via the list endpoint, without needing to know individual user IDs. - Stolen access tokens can be used to access external identity provider resources (Google Workspace, Azure AD, Okta-protected services) as the victim user. - Refresh tokens allow indefinite token renewal, persisting access even after the original access token expires. - Additionally, `admin`, `builder`, `tenantId`, `ssoId`, and `userGroups` fields are leaked, revealing the full authorization topology of the instance. ## Recommended Fix Strip sensitive SSO fields in `processUser()` at `packages/server/src/utilities/global.ts:15`: ```typescript export async function processUser( user: ContextUser, opts: { appId?: string; groups?: UserGroup[] } = {} ) { if (!user || (!user.roles && !user.userGroups)) { return user } user = cloneDeep(user) delete user.password + delete (user as any).oauth2 + delete (user as any).provider + delete (user as any).providerType + delete (user as any).thirdPartyProfile + delete (user as any).profile + delete (user as any).ssoId + delete (user as any).forceResetPassword // ... rest of function ``` Additionally, `getRawGlobalUsers()` at line 101 should also strip `oauth2` alongside its existing `password`/`forceResetPassword` stripping for defense in depth.
CVSS v3.1
Score 4.9medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in @budibase/server affects versions before 3.39.25. The `/api/users/metadata` and `/api/users/metadata/:id` endpoints return full global user profiles to users with POWER role or above. For users authenticated via SSO (OIDC, Google), the OAuth2 tokens (`accessToken` and `refreshToken`) are stored in the global CouchDB user document but are not stripped from the API responses. The endpoints only remove `password` and `roles` fields but leave the `oauth2` field intact. This results in leakage of sensitive OAuth2 tokens to unauthorized users with POWER role, enabling potential misuse of identity provider credentials. The recommended fix involves explicitly deleting the `oauth2` and other SSO-related sensitive fields in the user processing function and adding defense-in-depth stripping in the raw user fetch function.
Potential Impact
Users with POWER role in any Budibase app can access all SSO users' OAuth2 access and refresh tokens via the user metadata endpoints. This exposure allows unauthorized access to external identity provider resources (e.g., Google Workspace, Azure AD, Okta) as the victim user. Refresh tokens enable indefinite renewal of access, extending the window of compromise. Additionally, leakage of admin, builder, tenantId, ssoId, and userGroups fields reveals the full authorization topology of the instance, potentially aiding further attacks.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The recommended fix is to modify the `processUser()` function to delete the `oauth2` and other SSO-related sensitive fields before returning user metadata. Additionally, the `getRawGlobalUsers()` function should also strip the `oauth2` field for defense in depth. Until a patch is available, restrict POWER role assignments to trusted users only and monitor for suspicious access patterns to user metadata endpoints.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-fcrw-f7gg-6g9f
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["npm"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a6542309c2644c7f808a75c
Added to database: 07/25/2026, 23:09:36 UTC
Last enriched: 07/25/2026, 23:57:48 UTC
Last updated: 09/08/2026, 21:50:11 UTC
Views: 97
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.