CVE-2026-73304
Budibase: SSO OAuth2 Token Leakage via User Metadata Endpoints to Power-Role Users
Budibase is an open-source low-code platform. Prior to 3.39.25, GET /api/users/metadata and GET /api/users/metadata/:id returned user objects processed by packages/server/src/utilities/global.ts without removing oauth2.accessToken or oauth2.refreshToken. A user with the POWER role could retrieve the identity-provider credentials of SSO-authenticated users and use the refresh tokens for persistent access to connected services. This issue is fixed in version 3.39.25.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- High
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
4.9
Budibase: SSO OAuth2 Token Leakage via User Metadata Endpoints to Power-Role Users
Budibase is an open-source low-code platform. Prior to 3.39.25, GET /api/users/metadata and GET /api/users/metadata/:id returned user objects processed by packages/server/src/utilities/global.ts without removing oauth2.accessToken or oauth2.refreshToken. A user with the POWER role could retrieve the identity-provider credentials of SSO-authenticated users and use the refresh tokens for persistent access to connected services. This issue is fixed in version 3.39.25.
- Record
CVE-2026-73304- CVSS 3.1
- 4.9 Medium
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-200
- Updated
- 2026-11-02
EUVDEUVD-2026-58527
4.9
Budibase is an open-source low-code platform. Prior to 3.39.25, GET /api/users/metadata and GET /api/users/metadata/:id returned user objects processed by packages/server/src/utilities/global.ts without removing oauth2.accessToken or oauth2.refreshToken. A user with the POWER role could retrieve the identity-provider credentials of SSO-authenticated users and use the refresh tokens for persistent access to connected services. This issue is fixed in version 3.39.25.
- Record
EUVD-2026-58527- CVSS 3.1
- 4.9 Medium
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-fcrw-f7gg-6g9f
4.9
Budibase: SSO OAuth2 Token Leakage via User Metadata Endpoints to Power-Role Users
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:
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):
controller.fetchMetadata→sdk.users.fetchMetadata()(packages/server/src/sdk/users/utils.ts:78)- →
getGlobalUsers()→getRawGlobalUsers()(packages/server/src/utilities/global.ts:101-122) — strips onlypasswordandforceResetPassword - →
processUser()(packages/server/src/utilities/global.ts:15-76) — strips onlypasswordandroles - The
oauth2field containingaccessTokenandrefreshTokenis never removed
Path 2 — Single user (GET /api/users/metadata/:id):
controller.findMetadata→getFullUser()(packages/server/src/utilities/users.ts:6)- →
getGlobalUser()→getRawGlobalUser()(packages/server/src/utilities/global.ts:90-92) — raw CouchDB fetch, no field stripping at all - →
processUser()— strips onlypasswordandroles - Same result:
oauth2tokens 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:
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:
{
"accessToken": "ya29.a0ARrdaM...",
"refreshToken": "1//0eXxXxXxXx..."
}
Step 2 — Fetch a specific SSO user's profile:
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, anduserGroupsfields 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:
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…
- Record
GHSA-fcrw-f7gg-6g9f- CVSS 3.1
- 4.9 Medium
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-200
- Updated
- 2026-11-02
NVD
4.9
Budibase is an open-source low-code platform. Prior to 3.39.25, GET /api/users/metadata and GET /api/users/metadata/:id returned user objects processed by packages/server/src/utilities/global.ts without removing oauth2.accessToken or oauth2.refreshToken. A user with the POWER role could retrieve the identity-provider credentials of SSO-authenticated users and use the refresh tokens for persistent access to connected services. This issue is fixed in version 3.39.25.
- Record
CVE-2026-73304- CVSS 3.1
- 4.9 Medium
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-200
- Updated
- 2026-11-02
OSV
4.9
Budibase: SSO OAuth2 Token Leakage via User Metadata Endpoints to Power-Role Users
Budibase is an open-source low-code platform. Prior to 3.39.25, GET /api/users/metadata and GET /api/users/metadata/:id returned user objects processed by packages/server/src/utilities/global.ts without removing oauth2.accessToken or oauth2.refreshToken. A user with the POWER role could retrieve the identity-provider credentials of SSO-authenticated users and use the refresh tokens for persistent access to connected services. This issue is fixed in version 3.39.25.
- Record
CVE-2026-73304- CVSS 3.1
- 4.9 Medium
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-200
- Updated
- 2026-11-02
OSVGHSA-fcrw-f7gg-6g9f
4.9
Budibase: SSO OAuth2 Token Leakage via User Metadata Endpoints to Power-Role Users
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:
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):
controller.fetchMetadata→sdk.users.fetchMetadata()(packages/server/src/sdk/users/utils.ts:78)- →
getGlobalUsers()→getRawGlobalUsers()(packages/server/src/utilities/global.ts:101-122) — strips onlypasswordandforceResetPassword - →
processUser()(packages/server/src/utilities/global.ts:15-76) — strips onlypasswordandroles - The
oauth2field containingaccessTokenandrefreshTokenis never removed
Path 2 — Single user (GET /api/users/metadata/:id):
controller.findMetadata→getFullUser()(packages/server/src/utilities/users.ts:6)- →
getGlobalUser()→getRawGlobalUser()(packages/server/src/utilities/global.ts:90-92) — raw CouchDB fetch, no field stripping at all - →
processUser()— strips onlypasswordandroles - Same result:
oauth2tokens 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:
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:
{
"accessToken": "ya29.a0ARrdaM...",
"refreshToken": "1//0eXxXxXxXx..."
}
Step 2 — Fetch a specific SSO user's profile:
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, anduserGroupsfields 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:
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…
- Record
GHSA-fcrw-f7gg-6g9f- CVSS 3.1
- 4.9 Medium
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N - Weakness
- CWE-200
- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
@budibase/servernpm |
before 3.39.25 | 3.39.25 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-73304 is a medium vulnerability (CVSS 4.9) in Budibase, published July 24, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.48%, the 41st percentile. Fixed in @budibase/server 3.39.25.
References
github.com/Budibase/budibase/security/advisories/GHSA-fcrw-f7gg-6g9f
github.com/Budibase/budibase/pull/19110
github.com/Budibase/budibase/commit/80a31f6c3354620aa90e50af8a2c614333084621
github.com/Budibase/budibase/releases/tag/3.39.25
github.com/Budibase/budibase/commit/7b8ba11a2c8b233c35e7728dd752dba25ef919a4
github.com/advisories/GHSA-fcrw-f7gg-6g9f
github.com/CVEProject/cvelistV5/tree/main/cves/2026/73xxx/CVE-2026-73304.json
nvd.nist.gov/vuln/detail/CVE-2026-73304
github.com/Budibase/budibase
Left out here: the rest of 2 source descriptions. The JSON record has them.