CVEs

# 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. Wh

### Summary Budibase's central outbound-fetch guard (`fetchWithBlacklist`) prevents SSRF/DNS-rebinding by resolving the target hostname, checking every resolved IP against the blacklist, and **pinning** the connection to the validated IP. The pin is implemented as a Node `http(s).Agent` (`makePinnedAgent`). The fix for CVE-2026-54353 relies on this pin to stop DNS rebinding. The REST datasource integration (`@budibase/server`) calls `fetchWithBlacklist` but performs the actual request with **un

## Summary An end-user injection in Budibase's MongoDB datasource lets any BASIC app user bypass the builder's query-level access controls. Builders scope MongoDB reads per-user with bindings like `{"email": "{{ currentUser.email }}"}` so each app user only sees their own rows. Because the binding is handlebars-enriched into the query JSON with `noEscaping: true` and then `JSON.parse`d, Bob (a BASIC user) overrides the builder's filter with a MongoDB operator and reads every document the connec

## 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, b

### Summary The Budibase AI chat-link handoff flow (`GET/POST /api/chat-links/:instance/:token/handoff`) binds an **external chat identity** (Slack/Discord/MS Teams/Telegram) to a **Budibase user account**. The confirmation endpoint is on a **public route** (no CSRF middleware, no auth-group gate) and the only credential it checks is a `confirmationToken` that is **already rendered in plaintext into the HTML confirmation page** the victim views. There is no binding between the confirmation toke

### 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 ret

## Summary Budibase's MongoDB query execution endpoint (`POST /api/v2/queries/:queryId`) is vulnerable to NoSQL injection through user-supplied query parameters. The `enrichContext()` function interpolates parameter values into JSON query templates using Handlebars with `noEscaping: true`, then parses the result with `JSON.parse()`. An attacker can inject JSON metacharacters (`"`, `{`, `}`) into parameter values to alter the structure of MongoDB queries, bypassing intended filters to read, modi

## 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 `getUser

#### Summary The Budibase Worker service exposes a public, unauthenticated API endpoint (`GET /api/global/users/tenant/:id`) that returns sensitive user information including `tenantId`, `userId`, `email`, and `ssoId`. The endpoint is registered in the `PUBLIC_ENDPOINTS` list with a `TODO` comment acknowledging it "should be an internal API." Any unauthenticated party can enumerate user emails or IDs to extract sensitive tenant and user metadata, enabling targeted attacks against multi-tenant de

## Summary Budibase attaches a REST datasource's stored credentials (Bearer/Basic tokens and static headers) to an outgoing request before it decides which host the request goes to, and never checks that the destination host matches the datasource. A query's request path can be pointed at any host (via an absolute URL or a user-supplied `{{ parameter }}`), so the stored credentials are delivered to an attacker-chosen server. Because a query can be published with the PUBLIC role, this is reachabl

### 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 att

## Impact A builder-level user can make Budibase issue server-side HTTP requests to loopback or private-network targets by using DNS rebinding against two outbound fetch paths that are still not pinned to the validated DNS answer. The first path is OpenAPI query import. It validates the supplied hostname with the blacklist and then performs a separate raw fetch. A hostname that resolves to a public address during validation and to `127.0.0.1` during the request is accepted. The second path is

## Impact In Budibase v3.39.4, a regression in the authorization level for the S3 attachment upload endpoint allows any BASIC app user to obtain S3 PutObject presigned URLs. The endpoint uses TABLE/WRITE permission level instead of the intended BUILDER level defined in v3.39.3. Additionally, the controller does not pin the target bucket to the datasource's configured bucket, allowing writes to any S3 bucket the stored IAM credentials can access. ## Reproduction 1. As a BASIC app user, discove

## Summary When creating a MongoDB datasource, Budibase passes the `tlsCertificateKeyFile` and `tlsCAFile` fields straight to the MongoDB driver as server-side file paths. On Budibase Cloud a customer cannot place files on the server, so these fields only let a builder reference arbitrary absolute paths on the underlying multi-tenant server. When the datasource is verified, the driver performs a real filesystem read of that path, and the error differs by file state, turning `/api/datasources/ver

## Summary A critical SQL injection vulnerability was discovered in Budibase's MySQL integration that allows remote attackers to execute arbitrary SQL commands. ## Details ### Vulnerability Type SQL Injection ### Description The MySQL integration component in Budibase is configured with `multipleStatements: true`, enabling execution of multiple SQL statements in a single query. Attackers can inject malicious SQL commands through user input fields, leading to complete database compromise. ###

## 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 contro

## 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 use

## 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=inte