Budibase is an open-source low-code platform. Prior to 3.40.1, RestIntegration._req in packages/server/src/integrations/rest.ts attached credentials from getAuthHeaders and defaultHeaders without requiring the final request destination to match the datasource origin. An unauthenticated caller of a PUBLIC POST /api/v2/queries/:queryId query could supply an absolute or parameterized path to an attacker-controlled host and receive the stored bearer, basic, or static-header credentials. This issue is fixed in version 3.40.1.

Affected: npm: @budibase/server

## 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 reachable by a fully unauthenticated attacker with one HTTP request. The credentials are masked (`--secret-value--`) everywhere in the API, yet this recovers them in cleartext. This is a bypass of GHSA-3gp5 (which fixed the base-URL rewrite vector but added no same-origin check; the query-path vector remains, now unauthenticated).

## Root Cause `packages/server/src/integrations/rest.ts`: `_req()` builds `authHeaders = getAuthHeaders(...)` from the stored auth configs and merges them with `config.defaultHeaders` into every request, before the URL is resolved. `getUrl()`: if the (parameter-enriched) query `path` starts with `http`, the datasource base URL is ignored and `path` becomes the absolute request URL. There is no comparison between the resolved request host and the datasource base host before the credentials are attached. The execute route `POST /api/v2/queries/:queryId` runs under `authorized(QUERY, WRITE)`; a query published at role PUBLIC is executable with no session.

POC

##…

Ein Angreifer kann mehrere Schwachstellen in Budibase ausnutzen, um erweiterte Berechtigungen zu erlangen, SQL-Injection durchzuführen, Sicherheitsmaßnahmen zu umgehen, Konten zu übernehmen, Daten zu manipulieren oder offenzulegen sowie einen Denial-of-Service-Zustand auszulösen.