budibase-server

### Summary Budibase 3.39.7 allows a low-privilege authenticated published-app user with the built-in BASIC role to obtain arbitrary S3 pre-signed upload URLs backed by a workspace datasource's stored server-side credentials. The affected endpoint is: `POST /api/attachments/:datasourceId/url` The caller can control: ```text bucket key ``` and receives: ```text signedUrl publicUrl ``` This lets a low-privilege published-app user mint S3 `PUT` URLs using server-side datasource credentials for attacker-chosen object destinations. Steps: 1. Log in as an admin user. 2. Create a new app/worksp

CVE: CVE-2026-54356

## Summary Budibase automation steps (outgoing webhook, Zapier, n8n, Slack, Discord, Make.com) make server-side HTTP requests to user-provided URLs using `node-fetch` directly, completely bypassing the IP blacklist protection that exists in the REST API integration. Additionally, the REST API blacklist itself defaults to empty when `BLACKLIST_IPS` is not configured. ## Vulnerable Code ### Automation Steps (No Blacklist) All automation steps use `fetch()` directly without any IP validation: **`packages/server/src/automations/steps/outgoingWebhook.ts` line 69:** ```typescript const response

CVE: CVE-2026-35219

### Summary **This is a related but independently fixable vulnerability to GHSA-qqf5-x7mj-v43p (PostgreSQL SQL injection), reported in the same original disclosure and split per GitHub CNA guidance (rule 4.2.11) since it affects a separate integration, has a distinct attack precondition, and requires a separate patch.** The MySQL integration enables `multipleStatements: true` on the connection, permitting semicolon-separated multi-statement execution. During table introspection, table names retrieved from `INFORMATION_SCHEMA.TABLES` are interpolated into a `DESCRIBE` query wrapped in backtick

CVE: CVE-2026-73408

## Summary The `GET /api/global/groups` endpoint on the worker service has no role-based authorization middleware. Any authenticated user (including BASIC role) can enumerate all user groups in the tenant, including their role mappings, user memberships, builder permissions, and the isDefault flag. ## Steps to Reproduce ### 1. Start Budibase ```bash docker run -d --name budibase-poc -p 10000:80 \ -e MINIO_ACCESS_KEY=minio_access -e MINIO_SECRET_KEY=minio_secret \ -e INTERNAL_API_KEY=internal_api_key -e JWT_SECRET=jwt_secret_test \ -e API_ENCRYPTION_KEY=api_enc_key_test123456 \ -e B

CVE: CVE-2026-73301

## Summary `POST /api/v2/email` on the account portal (`account.budibase.app`) starts an email-change workflow using a client-supplied `accountId` that is **not validated against the authenticated session**. A logged-in attacker supplies a victim's `accountId` and an email address they control; the verification code is delivered to the attacker's address, and completing the workflow changes the **victim's** account email. The attacker then password-resets the victim's account through the controlled address and logs in — full account takeover with no victim interaction. ## Vulnerability Detai

CVE: CVE-2026-73303

## Summary The login lockout mechanism in Budibase creates an observable response discrepancy that allows unauthenticated attackers to enumerate valid email addresses. When an existing user's account is locked after 5 failed login attempts, the server returns a distinct `403` response with `X-Account-Locked: 1` and `Retry-After: 900` headers plus the message "Account temporarily locked." For non-existing users, the response is always a generic `403 "Unauthorized"` regardless of attempt count, because the lockout counter is never incremented. ## Details The vulnerability exists in two files

CVE: CVE-2026-73306

## 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 = { .

CVE: CVE-2026-73304

## Summary When an SSO-authenticated user tests an automation in the Budibase builder, their OAuth2 access token and refresh token are included in the automation test results. These results are broadcast via WebSocket to all builders connected to the same dev app and stored in an in-memory cache accessible to any builder who polls the test status endpoint. This allows any co-builder of the same app to steal the testing user's OAuth2 tokens. ## Details The vulnerability exists because `getUserContextBindings()` intentionally includes OAuth2 tokens in user context bindings (so automations can

CVE: CVE-2026-73308

# Budibase: SSRF via bare fetch() in uploadUrl during AI table generation ## Summary The `uploadUrl()` function in `packages/server/src/utilities/fileUtils.ts` uses a bare `fetch(url)` call without any SSRF protection. This function is invoked when the AI table generation feature processes LLM-generated attachment column values that are strings (URLs). A builder-level user can craft prompts that cause the LLM to generate internal IP addresses or cloud metadata endpoints as attachment URLs. When `generateRows()` calls `processAttachments()`, these URLs are fetched server-side without blackli

CVE: CVE-2026-73307

### Summary Budibase's OIDC SSO login links an incoming SSO identity to an existing Budibase account **by email address alone**, without ever checking the `email_verified` claim of the OIDC ID token. Budibase first tries to match the IdP `sub`; when that misses (any fresh attacker IdP account) it silently falls back to matching by the `email` claim and **merges into the existing account by email**, preserving that account's `_id` and roles. Because the `email_verified` flag is never read, an attacker who can make a **configured/trusted** IdP emit a token carrying `email = <victim>` with `email

CVE: CVE-2026-73302