{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/backend-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.39.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54353"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T23:39:24Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Summary\n\nAuthenticated users with automation permissions can bypass Budibase\u0027s SSRF blacklist through DNS rebinding.\n\nThe outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection.\n\nThis results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints.\n\nDetails\n\nThe issue comes from the outbound fetch validation flow resolving DNS twice:\n\nDuring blacklist validation\nAgain during the real socket connection\n\nThe first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP.\n\nThis creates a classic TOCTOU DNS rebinding issue.\n\nAffected flow in:\n\npackages/backend-core/src/utils/outboundFetch.ts\n```\nasync function throwIfUnsafe(url: string): Promise\u003cvoid\u003e {\n  const parsed = parseUrl(url)\n\n  if (await isBlacklisted(parsed.hostname)) {\n    throw new Error(\"URL is blocked or could not be resolved safely.\")\n  }\n}\n\nfor (let redirects = 0; redirects \u003c= MAX_REDIRECTS; redirects++) {\n  await throwIfUnsafe(nextUrl)\n\n  const response = await fetchFn(nextUrl, nextRequest)\n\n  // ...\n}\n```\nfetchFn uses plain node-fetch with no custom http.Agent / https.Agent, so the underlying socket performs its own independent dns.lookup after validation completes.\n\nThe same pattern also exists in:\n\npackages/server/src/automations/steps/utils.ts\n```\nawait throwIfBlacklisted(nextUrl)\n\nconst response = await fetch(nextUrl, nextRequest)\n```\nThe blacklist implementation resolves hostnames but only returns a boolean:\n\npackages/backend-core/src/blacklist/blacklist.ts\n```\nasync function lookup(address: string): Promise\u003cstring[]\u003e {\n  address = parseAddress(address)\n\n  const addresses = await performLookup(address, { all: true })\n\n  return addresses.map(addr =\u003e addr.address)\n}\n\nexport async function isBlacklisted(address: string): Promise\u003cboolean\u003e {\n  // ...\n\n  if (!net.isIP(address)) {\n    try {\n      ips = await lookup(address)\n    } catch (e) {\n      /* ... */\n    }\n  } else {\n    ips = [address]\n  }\n\n  return ips.some(ip =\u003e blackList!.check(ip, getIpVersion(ip)))\n}\n```\nThe resolved IPs are discarded, so callers cannot pin the later socket connection to the validated addresses.\n\nAn attacker controlling authoritative DNS for a hostname can therefore return:\n\na public IP during validation\na private/internal IP during the actual connection\n\nAnything routing through these helpers inherits the issue, including:\n\noutgoing webhook\nSlack\nDiscord\nMake\nZapier\nn8n\nAI extract\nobject-store fetches\n\nSeveral of these steps return upstream response content directly into automation output, which makes the SSRF non-blind.\n\nPoC\n\nTested locally against a self-hosted build from master.\nNo Budibase-operated infrastructure was touched.\n\nRun Budibase locally.\n\nStart a harmless local HTTP listener:\n\npython3 -m http.server 8080 --bind 127.0.0.1\n\nUse a rebinding hostname such as:\n\n7f000001.cb007264.rbndr.us\n\nwhich rotates between:\n\n127.0.0.1\n203.0.113.100\n\nSteps to reproduce:\n\nLog into Budibase with automation permissions.\nCreate an automation using the Outgoing Webhook step.\nSet the URL to:\nhttp://\u003crebinding-host\u003e:8080/\nTrigger the automation.\n\nObserved result:\n\nThe blacklist validation resolves the hostname to the public IP and allows the request.\nnode-fetch performs a second DNS lookup during socket creation.\nThe second lookup resolves to 127.0.0.1.\nThe TCP connection lands on the local service.\nThe local server response body appears directly in the automation output.\nImpact\n\nThis produces a non-blind read-SSRF primitive against anything reachable from the Budibase host process, including:\n\nloopback services (127.0.0.1)\nRFC1918 ranges\ninternal Kubernetes/VPC services\ncloud metadata endpoints (169.254.169.254)\n\nOn cloud deployments without IMDSv2 enforcement, this may expose temporary IAM credentials via:\n\n/latest/meta-data/iam/security-credentials/\u003crole\u003e\n\nOn multi-tenant hosted deployments, this may also create potential cross-tenant access paths through shared internal infrastructure.",
  "id": "GHSA-gfq7-5x4g-3xhf",
  "modified": "2026-06-22T23:39:24Z",
  "published": "2026-06-22T23:39:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-gfq7-5x4g-3xhf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@budibase/backend-core has potential SSRF DNS rebinding bypass in outbound fetch validation"
}