GHSA-xg5g-26x8-cvf4: Budibase DNS Rebinding SSRF Bypasses Remain Vulnerability

HIGH
CVSS 8.5
CWE-918
Published
Advisory Summary

GHSA-xg5g-26x8-cvf4 is a HIGH (CVSS 8.5) dns rebinding ssrf bypasses remain vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting Budibase libraries in the npm ecosystem. The issue involves dns rebinding ssrf bypasses remain in openapi import and rest query execution. Remediation is available in the latest vendor maintenance releases.

GHSA-xg5g-26x8-cvf4 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-xg5g-26x8-cvf4
Severity HIGH
CVSS v3.1 Base Score 8.5
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product Budibase
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 8.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix GHSA-xg5g-26x8-cvf4

To remediate this vulnerability, upgrade all affected Budibase dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@budibase/server fixed: Latest secure release
npm install @budibase/server@Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @budibase/server

How to Check if You Are Affected

To determine whether your Node.js application is affected by GHSA-xg5g-26x8-cvf4, inspect your project dependencies using npm:

npm ls @budibase/server

Analyze the terminal output to locate any version of Budibase in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: The npm ls @budibase/server command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where the web server receives a url or similar request from an upstream component and retrieves the contents of this url, but it does not sufficiently ensure that the request is being sent to the expected destination. In Budibase, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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 REST datasource/query execution. It calls the fixed `fetchWithBlacklist()` helper, but provides a custom undici `fetchFn` that installs a `dispatcher`. The helper passes a pinned Node `agent`, but undici uses the dispatcher and resolves the original hostname again at connection time. This defeats the DNS pinning added for the previous outbound fetch advisory. Impact is authenticated SSRF from the Budibase server process. An attacker with the relevant builder/query privileges can reach loopback or private HTTP services that should be blocked by Budibase's outbound fetch protections, subject to the normal response handling of each feature. ## Reproduction 1. Configure an attacker-controlled hostname so the validation lookup returns a public IP address and the later request lookup returns an internal address such as `127.0.0.1`. 2. Start a loopback canary HTTP service on the Budibase host. 3. For OpenAPI query import, submit an import URL such as `http://rebind.test:<port>/openapi.json` through the builder query import endpoints. In a harness matching the current import code, validation resolved `rebind.test` to `8.8.8.8`, the raw fetch then resolved `rebind.test` to `127.0.0.1`, and the loopback canary returned `loopback-canary-hit:/openapi.json`. 4. For REST datasource/query execution, configure a REST datasource/query URL using the same rebinding hostname. In a harness matching the current helper plus REST undici custom fetch path, a direct loopback URL was blocked and a pinned Node-agent control did not hit loopback, but the REST undici path re-resolved the hostname to `127.0.0.1` and returned `REST-UNDICI-REBIND-CANARY` from the loopback service. Observed OpenAPI import proof: ```json { "outcome": "allowed", "body": "loopback-canary-hit:/openapi.json", "lookups": [ {"phase": "guard", "hostname": "rebind.test", "address": "8.8.8.8"}, {"phase": "fetch", "hostname": "rebind.test", "address": "127.0.0.1"} ] } ``` Observed REST undici proof: ```json { "directControl": {"outcome": "blocked", "hitsAfter": 0}, "pinnedNodeFetchControl": {"outcome": "no_loopback_hit", "hitsAfter": 0}, "undiciBypass": { "outcome": "allowed", "status": 200, "body": "REST-UNDICI-REBIND-CANARY", "hitsAfter": 1 }, "lookupTrace": [ {"phase": "guard", "hostname": "rebind.test", "address": "8.8.8.8"}, {"phase": "fetch", "hostname": "rebind.test", "address": "127.0.0.1"} ] } ``` ## Root cause and technical details The central helper now resolves and validates the target hostname, then passes a pinned Node `http.Agent` or `https.Agent` to the request. That protects callers whose HTTP client honors the Node `agent` option. OpenAPI query import does not use that helper. In `packages/server/src/api/controllers/query/import/index.ts`, `assertUrlIsSafe()` calls `blacklist.isBlacklisted(parsed.hostname)`, but `fetchFromUrl()` then calls `fetch(currentUrl, { redirect: "manual" })`. That creates a validate-then-fetch gap where DNS can change between the blacklist lookup and the actual connection. REST datasource/query execution uses the helper but changes the transport semantics. In `packages/server/src/integrations/rest.ts`, `setDispatcher()` creates an undici dispatcher with `getDispatcher({ rejectUnauthorized, url: requestUrl })`, then the custom fetch function calls `fetch(requestUrl, setDispatcher(requestInput, requestUrl))`. In `packages/backend-core/src/utils/outboundFetch.ts`, `fetchWithBlacklist()` passes the pinned Node `agent` to `fetchFn`, but undici fetch uses the supplied `dispatcher` instead. The actual connection performs a second hostname resolution and can be rebound to a blocked address. Current affected code is present in latest `master` and in the latest release tag `3.39.14`. ## Remediation Route OpenAPI query import through the pinned outbound fetch helper rather than validating and raw-fetching separately. Make `fetchWithBlacklist()` pin the actual connection for every supported transport. For undici callers, provide a dispatcher whose lookup or connect behavior is pinned to the validated IP, or reject custom fetch functions that do not explicitly enforce the pinned address. Add regression coverage for direct loopback blocking, DNS rebinding through OpenAPI import, DNS rebinding through REST undici dispatcher, redirect-to-loopback, IPv4-mapped IPv6, and mixed public/private DNS answers.

GHSA-xg5g-26x8-cvf4 Affected Budibase Versions

1 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
@budibase/server
npm
≤ 3.38.1

References

Frequently Asked Questions

What is GHSA-xg5g-26x8-cvf4?
GHSA-xg5g-26x8-cvf4 is a security vulnerability in Budibase involving DNS rebinding SSRF bypasses remain in OpenAPI import and REST query execution under CWE-918: Server-Side Request Forgery (SSRF).
Which Budibase versions are affected?
Affected versions include releases prior to current release patches across affected packages: @budibase/server.
What version fixes GHSA-xg5g-26x8-cvf4?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is @budibase/server affected?
Yes, @budibase/server is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of GHSA-xg5g-26x8-cvf4?
GHSA-xg5g-26x8-cvf4 has a CVSS v3.1 base score of 8.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N.
What CWE is associated with GHSA-xg5g-26x8-cvf4?
GHSA-xg5g-26x8-cvf4 is classified under CWE-918: Server-Side Request Forgery (SSRF) (The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.).
How can I check npm dependencies for GHSA-xg5g-26x8-cvf4?
Run the dependency tree command: 'npm ls @budibase/server'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-xg5g-26x8-cvf4",
  "modified" : "2026-07-24T21:17:25Z",
  "published" : "2026-07-24T21:17:25Z",
  "aliases" : [ ],
  "summary" : " Budibase: DNS rebinding SSRF bypasses remain in OpenAPI import and REST query execution",
  "details" : "## Impact\n\nA 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.\n\nThe 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.\n\nThe second path is REST datasource/query execution. It calls the fixed `fetchWithBlacklist()` helper, but provides a custom undici `fetchFn` that installs a `dispatcher`. The helper passes a pinned Node `agent`, but undici uses the dispatcher and resolves the original hostname again at connection time. This defeats the DNS pinning added for the previous outbound fetch advisory.\n\nImpact is authenticated SSRF from the Budibase server process. An attacker with the relevant builder/query privileges can reach loopback or private HTTP services that should be blocked by Budibase's outbound fetch protections, subject to the normal response handling of each feature.\n\n## Reproduction\n\n1. Configure an attacker-controlled hostname so the validation lookup returns a public IP address and the later request lookup returns an internal address such as `127.0.0.1`.\n2. Start a loopback canary HTTP service on the Budibase host.\n3. For OpenAPI query import, submit an import URL such as `http://rebind.test:<port>/openapi.json` through the builder query import endpoints. In a harness matching the current import code, validation resolved `rebind.test` to `8.8.8.8`, the raw fetch then resolved `rebind.test` to `127.0.0.1`, and the loopback canary returned `loopback-canary-hit:/openapi.json`.\n4. For REST datasource/query execution, configure a REST datasource/query URL using the same rebinding hostname. In a harness matching the current helper plus REST undici custom fetch path, a direct loopback URL was blocked and a pinned Node-agent control did not hit loopback, but the REST undici path re-resolved the hostname to `127.0.0.1` and returned `REST-UNDICI-REBIND-CANARY` from the loopback service.\n\nObserved OpenAPI import proof:\n\n```json\n{\n  \"outcome\": \"allowed\",\n  \"body\": \"loopback-canary-hit:/openapi.json\",\n  \"lookups\": [\n    {\"phase\": \"guard\", \"hostname\": \"rebind.test\", \"address\": \"8.8.8.8\"},\n    {\"phase\": \"fetch\", \"hostname\": \"rebind.test\", \"address\": \"127.0.0.1\"}\n  ]\n}\n```\n\nObserved REST undici proof:\n\n```json\n{\n  \"directControl\": {\"outcome\": \"blocked\", \"hitsAfter\": 0},\n  \"pinnedNodeFetchControl\": {\"outcome\": \"no_loopback_hit\", \"hitsAfter\": 0},\n  \"undiciBypass\": {\n    \"outcome\": \"allowed\",\n    \"status\": 200,\n    \"body\": \"REST-UNDICI-REBIND-CANARY\",\n    \"hitsAfter\": 1\n  },\n  \"lookupTrace\": [\n    {\"phase\": \"guard\", \"hostname\": \"rebind.test\", \"address\": \"8.8.8.8\"},\n    {\"phase\": \"fetch\", \"hostname\": \"rebind.test\", \"address\": \"127.0.0.1\"}\n  ]\n}\n```\n\n## Root cause and technical details\n\nThe central helper now resolves and validates the target hostname, then passes a pinned Node `http.Agent` or `https.Agent` to the request. That protects callers whose HTTP client honors the Node `agent` option.\n\nOpenAPI query import does not use that helper. In `packages/server/src/api/controllers/query/import/index.ts`, `assertUrlIsSafe()` calls `blacklist.isBlacklisted(parsed.hostname)`, but `fetchFromUrl()` then calls `fetch(currentUrl, { redirect: \"manual\" })`. That creates a validate-then-fetch gap where DNS can change between the blacklist lookup and the actual connection.\n\nREST datasource/query execution uses the helper but changes the transport semantics. In `packages/server/src/integrations/rest.ts`, `setDispatcher()` creates an undici dispatcher with `getDispatcher({ rejectUnauthorized, url: requestUrl })`, then the custom fetch function calls `fetch(requestUrl, setDispatcher(requestInput, requestUrl))`. In `packages/backend-core/src/utils/outboundFetch.ts`, `fetchWithBlacklist()` passes the pinned Node `agent` to `fetchFn`, but undici fetch uses the supplied `dispatcher` instead. The actual connection performs a second hostname resolution and can be rebound to a blocked address.\n\nCurrent affected code is present in latest `master` and in the latest release tag `3.39.14`.\n\n## Remediation\n\nRoute OpenAPI query import through the pinned outbound fetch helper rather than validating and raw-fetching separately.\n\nMake `fetchWithBlacklist()` pin the actual connection for every supported transport. For undici callers, provide a dispatcher whose lookup or connect behavior is pinned to the validated IP, or reject custom fetch functions that do not explicitly enforce the pinned address. Add regression coverage for direct loopback blocking, DNS rebinding through OpenAPI import, DNS rebinding through REST undici dispatcher, redirect-to-loopback, IPv4-mapped IPv6, and mixed public/private DNS answers.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@budibase/server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "3.38.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/security/advisories/GHSA-xg5g-26x8-cvf4"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/pull/19178"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/commit/1fecb3fc3497e8db7b60b42cc514ce304ffe3a41"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/commit/5758bdb242802ca20c4ed0dc579e4330ee898ef3"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/commit/586802b5706367520d14245e18a7d0cabab0be11"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Budibase/budibase"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/releases/tag/3.39.30"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-24T21:17:25Z",
    "nvd_published_at" : null
  }
}