CVE-2026-48146 - Budibase OAuth2 validation SSRF

Budibase before 3.39.0 fetched OAuth2 token URLs with raw fetch() during validation instead of using the platform’s safer outbound request wrapper. A builder-level user could point the OAuth2 token URL at internal services or metadata endpoints and use the validation flow as an SSRF primitive.

This is especially serious in low-code control planes that already hold database credentials, automation secrets, or private network reachability.

When to use it

Use this recipe when a repository deploys, forks, packages, or configures Budibase and allows builders or semi-trusted users to configure OAuth2-backed integrations. It is most important for low-code control planes with access to internal services, cloud metadata, object stores, management APIs, databases, automation secrets, or private network egress.

Use it to upgrade the server and prove OAuth2 token validation uses the same safe outbound controls as other platform fetches. Do not use it to probe live internal services or metadata endpoints.

Inputs

  • @budibase/server package manifests, lockfiles, images, charts, deployment manifests, SBOMs, generated dependency reports, forks, and local patches.
  • OAuth2 integration validation paths, token URL handling, redirect handling, outbound fetch wrappers, blacklist/allow-list policy, and any raw fetch() usage around builder-controlled config.
  • Builder/admin role model and evidence of who can configure OAuth2 data sources or integrations.
  • Network exposure for the Budibase runtime: internal HTTP services, metadata endpoints, object stores, management planes, private DNS, and egress policy.
  • Logs or audit trails needed for review, with internal URLs, tokens, credentials, and automation secrets treated as sensitive.

Affected versions

  • Vulnerable: @budibase/server <3.39.0
  • Fixed: @budibase/server 3.39.0+
  • Affected surface: OAuth2 token URL validation and any deployment where builders can configure OAuth2-backed integrations

Indicator-of-exposure

  • The repository deploys Budibase server versions before 3.39.0.
  • Builders or semi-trusted internal users can configure OAuth2 integrations.
  • The deployment has network access to internal HTTP services, cloud metadata, object stores, or management planes.

Quick checks:

rg -n "budibase|oauth2|fetchWithBlacklist|outboundFetch|config\\.url|token URL|builder" .
npm ls @budibase/server
pnpm why @budibase/server

Windows:

rg -n "budibase|oauth2|fetchWithBlacklist|outboundFetch|config\\.url|token URL|builder" .
npm ls @budibase/server
pnpm why @budibase/server

Remediation strategy

  • Upgrade Budibase to 3.39.0+.
  • Ensure OAuth2 token fetches use the same blacklist and redirect-aware egress controls applied to other outbound HTTP features.
  • Restrict builder-controlled outbound destinations where the platform permits.
  • Review egress logs and sensitive internal services if vulnerable builders had access before patching.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-48146 / GHSA-g6qx-g4pr-92v7 in Budibase. OAuth2
validation can SSRF internal services because token fetches bypass the normal
outbound blacklist wrapper. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Budibase, restores safe
  egress controls, adds regression checks, and documents review actions, or
- TRIAGE.md if this repository does not control an affected Budibase server.

## Rules

- Scope only CVE-2026-48146 and directly related OAuth2 validation egress.
- Treat internal URLs, metadata endpoints, credentials, and automation secrets
  as sensitive.
- Do not probe live internal services or metadata endpoints.
- Do not weaken existing outbound security controls to preserve behavior.
- Do not auto-merge.

## Steps

1. Inventory every `@budibase/server` dependency, image, chart, and deployment
   manifest controlled by this repository.
2. Confirm the resolved Budibase version and whether builders can configure
   OAuth2 integrations.
3. Identify the code or deployment path used for OAuth2 token validation and
   how egress filtering is enforced.
4. If this repository does not control an affected Budibase server, stop with
   `TRIAGE.md` naming the owner and required fixed version `3.39.0+`.
5. Upgrade to `3.39.0+` and refresh locks, images, SBOMs, and deployment
   artifacts.
6. Ensure OAuth2 token fetches route through the safe outbound blacklist and
   redirect-check logic used elsewhere in the platform.
7. Add safe regression checks proving builder-controlled OAuth2 config cannot
   target disallowed destinations, without contacting internal endpoints.
8. Add a PR body section named `CVE-2026-48146 operator actions` covering:
   - versions before and after;
   - whether builders could reach internal egress;
   - what egress review or credential review is required;
   - validation that passed.
9. Run available validation: dependency install, tests, build, image build,
   deployment render, and security scans.
10. Use PR title:
    `fix(sec): remediate CVE-2026-48146 in Budibase OAuth2 validation`.

## Stop conditions

- No affected Budibase server is controlled by this repository.
- Verification would require probing live internal or metadata services.
- Product requirements intentionally allow unrestricted builder-controlled
  outbound fetches; document the risk and stop for review.
- Validation fails for unrelated pre-existing reasons; document those failures.

Verification - what the reviewer looks for

  • No controlled Budibase deployment resolves <3.39.0.
  • OAuth2 validation uses the same blacklist and redirect protections as other outbound fetch paths.
  • Regression tests fail closed on disallowed destinations.

Watch for

  • Upgrading the package while a local patch or fork still uses raw fetch().
  • Filtering only the first URL and not redirects.
  • Assuming internal-only deployment means SSRF is harmless.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades Budibase to 3.39.0+, routes OAuth2 token validation through safe outbound filtering and redirect checks, adds regression coverage for disallowed destinations, refreshes generated artifacts, and documents egress/credential review actions.
  • TRIAGE.md when no controlled affected Budibase server, fork, image, chart, deployment, or OAuth2 validation path exists.

The output must list versions before/after, builder reachability, egress controls applied, internal-destination protections, validation commands, artifacts refreshed, and any logs or credentials requiring review. It must not probe live internal endpoints, print internal URLs unnecessarily, expose metadata responses, weaken outbound controls, or claim SSRF is harmless because the deployment is internal.

References