VYPR
← All advisories
High severity8.5NVD Advisory· Published May 27, 2026· Updated May 27, 2026

CVE-2026-48153

CVE-2026-48153

Description

Budibase is an open-source low-code platform. Prior to 3.39.0, fetchToken in the OAuth2 SDK makes a POST to a builder-supplied URL with plain node-fetch, skipping the blacklist.isBlacklisted check that every other outbound fetch path in the codebase uses. The Joi schema for the OAuth2 URL has no scheme or host restriction. This vulnerability is fixed in 3.39.0.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Budibase OAuth2 token endpoint request lacks SSRF protection, allowing builders to access internal hosts and cloud metadata.

Vulnerability

In Budibase versions prior to 3.39.0, the fetchToken function in the OAuth2 SDK makes a POST request to a builder-supplied URL without performing the blacklist.isBlacklisted check that is used in all other outbound fetch paths. The Joi schema for the OAuth2 URL has no scheme or host restriction, allowing arbitrary URLs. This affects the /api/oauth2/validate endpoint accessible to builders [1].

Exploitation

An attacker with builder privileges can configure an OAuth2 integration to point at internal addresses such as http://127.0.0.1:5984/ or cloud metadata endpoints like http://169.254.169.254/. The server fetches the URL and returns the response body (including error messages) in the validation result. The default redirect: "follow" setting allows redirects from an external URL to internal targets [1].

Impact

Successful exploitation leads to Server-Side Request Forgery (SSRF), enabling the attacker to reach internal services and cloud metadata endpoints. This can result in disclosure of sensitive information, such as cloud instance metadata or internal service data [1].

Mitigation

The vulnerability is fixed in Budibase version 3.39.0. Users should upgrade to the latest version. No workaround is available [1].

References
  1. SSRF via OAuth2 token endpoint URL reaches internal hosts and cloud metadata

AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Budibase/Budibaseinferred2 versions
    <3.39.0+ 1 more
    • (no CPE)range: <3.39.0
    • (no CPE)range: <3.39.0

Patches

1
feab9955aeb5

Bump version to 3.39.0

https://github.com/Budibase/budibaseBudibase Staging Release BotMay 20, 2026Fixed in 3.39.0via release-tag
commit
1 file changed · +1 −1
  • lerna.json+1 −1 modified
    @@ -1,6 +1,6 @@
 {
   "$schema": "node_modules/lerna/schemas/lerna-schema.json",
-  "version": "3.38.5",
+  "version": "3.39.0",
   "npmClient": "yarn",
   "concurrency": 20,
   "command": {

Vulnerability mechanics

Root cause

"Missing blacklist check in fetchToken allows SSRF to internal hosts and cloud metadata endpoints."

Attack vector

An attacker with a builder account sends a POST to `/api/oauth2/validate` with a crafted JSON body containing a `url` pointing to an internal host (e.g., `http://127.0.0.1:5984/` or `http://169.254.169.254/latest/meta-data/`). The server makes a plain node-fetch POST to that URL without consulting the blacklist, and the response body (or error message) is reflected back in the validation result. Because `redirect: "follow"` is the default, a public URL that returns a 302 to an internal target also works [ref_id=1].

Affected code

The vulnerable function is `fetchToken` in `packages/server/src/sdk/workspace/oauth2/utils.ts` (lines 17-65). It calls `fetch(config.url, fetchConfig)` with plain node-fetch and default `redirect: "follow"`, skipping the `blacklist.isBlacklisted` check that every other outbound fetch path uses. The validation route in `packages/server/src/api/routes/oauth2.ts` accepts any string for the URL with no scheme or host restriction [ref_id=1].

What the fix does

The patch [patch_id=2725521] adds a call to `blacklist.isBlacklisted(config.url)` before the fetch in `fetchToken`, throwing an error if the URL is blocked. It also sets `redirect: "manual"` on the fetch config so that redirect targets are not automatically followed without re-validation. This matches the pattern already used in `outboundFetch.ts` and ensures the OAuth2 token endpoint path respects the same IP blacklist (127.0.0.0/8, 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) that every other outbound fetch in the codebase uses [ref_id=1].

Preconditions

  • authAttacker must have a builder account on the Budibase instance (free-tier signup on Budibase Cloud is sufficient)
  • networkAttacker must be able to send HTTP POST requests to the /api/oauth2/validate endpoint
  • inputAttacker must supply a JSON body with a url field pointing to an internal or cloud metadata endpoint

Reproduction

Step 1: As a builder, POST an OAuth2 config pointed at CouchDB on the same host: `curl -sS -b "$BUILDER_COOKIE" -X POST "$BASE/api/oauth2/validate" -H "Content-Type: application/json" -d '{"url":"http://127.0.0.1:5984/","clientId":"t","clientSecret":"t","method":"BODY","grantType":"client_credentials"}'`. The server response `{"valid":false,"message":"Method Not Allowed"}` confirms Budibase reached CouchDB (which rejects POST at / with 405). Step 2: Probe the cloud metadata endpoint: `curl -sS -b "$BUILDER_COOKIE" -X POST "$BASE/api/oauth2/validate" -H "Content-Type: application/json" -d '{"url":"http://169.254.169.254/latest/meta-data/","clientId":"t","clientSecret":"t","method":"BODY","grantType":"client_credentials"}'`. The response leaks the upstream body: `{"valid":false,"message":"invalid json response body at http://169.254.169.254/latest/meta-data/ reason: Unexpected token 'N', \"Not Found\" is not valid JSON"}` [ref_id=1].

Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

1

News mentions

0

No linked articles in our index yet.