CVE-2026-54353: 
JavaScript 脆弱性の分析と軽減

CVE-2026-54353 is a Server-Side Request Forgery (SSRF) vulnerability via DNS rebinding in the @budibase/backend-core npm package, affecting Budibase versions prior to 3.39.9. Authenticated users with automation permissions can bypass Budibase's SSRF blacklist by exploiting a Time-of-Check Time-of-Use (TOCTOU) race condition in the outbound fetch validation flow. The vulnerability was published on June 4, 2026, and added to the GitHub Advisory Database on June 22, 2026. It carries a CVSS v3.1 base score of 8.5 (High) (GitHub Advisory, Budibase Advisory).

The root cause is a classic TOCTOU DNS rebinding flaw (CWE-367, CWE-918) in packages/backend-core/src/utils/outboundFetch.ts. The throwIfUnsafe() function resolves a hostname via isBlacklisted() and checks the resulting IPs against a blacklist, but then discards those resolved IPs — it does not pin them to the subsequent socket connection. When fetchFn (plain node-fetch with no custom http.Agent) later opens the TCP connection, it performs an independent second DNS lookup, which an attacker-controlled authoritative DNS server can resolve to a private/internal IP (e.g., 127.0.0.1, RFC1918, or 169.254.169.254). The same vulnerable pattern exists in packages/server/src/automations/steps/utils.ts. Because several automation steps (outgoing webhook, Slack, Discord, Make, Zapier, n8n, AI extract, object-store fetches) return upstream response content directly into automation output, the SSRF is non-blind (GitHub Advisory, Budibase Advisory).

Successful exploitation yields a non-blind read-SSRF primitive against any service reachable from the Budibase host process, including loopback services (127.0.0.1), RFC1918 ranges, internal Kubernetes/VPC services, and cloud metadata endpoints (169.254.169.254). On cloud deployments without IMDSv2 enforcement, an attacker can retrieve temporary IAM credentials via /latest/meta-data/iam/security-credentials/, potentially enabling privilege escalation or lateral movement within the cloud environment. On multi-tenant hosted deployments, this may also create cross-tenant access paths through shared internal infrastructure (GitHub Advisory, Budibase Advisory).

1. Obtain automation permissions: Log into a Budibase instance with an account that has automation creation/execution permissions.
2. Set up a DNS rebinding hostname: Use a public DNS rebinding service (e.g., rbndr.us) to create a hostname that alternates between a public IP (e.g., 203.0.113.100) and the target internal IP (e.g., 127.0.0.1). Example: 7f000001.cb007264.rbndr.us.
3. Start a listener on the target internal service: On the Budibase host or an internal service, run a listener (e.g., python3 -m http.server 8080 --bind 127.0.0.1) or identify an existing internal service to probe (e.g., cloud metadata endpoint at 169.254.169.254).
4. Create a malicious automation: In Budibase, create a new automation using the Outgoing Webhook step (or Slack, Discord, Make, n8n, etc.) and set the URL to the rebinding hostname, e.g., http://7f000001.cb007264.rbndr.us:8080/.
5. Trigger the automation: Execute the automation. The throwIfUnsafe() validation resolves the hostname to the public IP and passes the blacklist check.
6. DNS rebinding occurs: When node-fetch opens the actual TCP connection, it performs a second DNS lookup. The attacker's DNS server now returns the private/internal IP (e.g., 127.0.0.1).
7. Retrieve response: The TCP connection lands on the internal service, and the response body is returned directly in the automation output, completing a non-blind SSRF read (GitHub Advisory, Budibase Advisory).

• Network: Outbound DNS queries from the Budibase host to attacker-controlled authoritative DNS servers with very short TTLs (TTL ≤ 1s), characteristic of DNS rebinding; TCP connections from the Budibase process to loopback (127.0.0.1) or RFC1918 addresses on unexpected ports; HTTP requests to 169.254.169.254 (cloud metadata endpoint) originating from the Budibase process.
• Logs: Budibase automation execution logs showing webhook/fetch steps targeting hostnames that resolve to internal IPs; automation output containing internal service responses, IAM credential JSON, or Kubernetes service discovery data.
• Process: Unusual outbound connections from the Node.js Budibase server process to internal network ranges or loopback addresses not associated with normal application behavior.

Budibase has released a patched version: @budibase/backend-core 3.39.9, which resolves the DNS rebinding bypass. Users should upgrade to version 3.39.9 or later immediately. As a defense-in-depth measure, operators should enforce IMDSv2 on cloud deployments to prevent metadata endpoint access, apply network-level egress controls to block Budibase host connections to RFC1918 and loopback ranges, and restrict automation permissions to trusted users only (GitHub Advisory, Budibase Advisory).