Listen to this Post
How the CVE Works
The vulnerability stems from a Time-of-Check to Time-of-Use (TOCTOU) race condition in Budibase’s outbound request validation flow, specifically within the `outboundFetch.ts` utility. When an authenticated user with automation permissions triggers an outbound request (e.g., via an Outgoing Webhook step), the system performs a security validation to ensure the target hostname does not resolve to a private or internal IP address. This validation is handled by the `throwIfUnsafe` function, which parses the URL and calls `isBlacklisted` on the hostname.
The `isBlacklisted` function resolves the hostname to one or more IP addresses using a DNS lookup and checks these against an internal blacklist of forbidden ranges (e.g., loopback, RFC1918, and cloud metadata addresses). However, a critical design flaw exists: the IP addresses resolved during this validation are discarded immediately after the check. The system does not pin or associate these validated IPs with the subsequent network connection.
After the validation passes, the actual HTTP request is made using the `fetchFn` function, which relies on the underlying `node-fetch` library. `node-fetch` performs its own independent DNS lookup when establishing the socket connection. This second lookup occurs after the validation has already completed, creating a window for a DNS rebinding attack. An attacker who controls the authoritative DNS server for a given hostname can return a public, non-blacklisted IP address during the initial validation phase. Then, for the subsequent `node-fetch` DNS lookup, the attacker’s DNS server returns a different, private/internal IP address (e.g., 127.0.0.1, 169.254.169.254).
Because the validated IPs are never pinned to the connection, the system accepts the second, malicious DNS response and establishes a TCP connection to the internal address. This effectively bypasses the SSRF blacklist. The same vulnerable pattern exists in other parts of the codebase, such as packages/server/src/automations/steps/utils.ts. The impact is severe, as several automation steps (Outgoing Webhook, Slack, Discord, Make, Zapier, n8n, AI extract, object-store fetches) return the upstream response directly into the automation output, making the SSRF non-blind and allowing attackers to read data from internal services.
DailyCVE Form
Platform: Budibase
Version: <3.34.8
Vulnerability: SSRF (DNS Rebinding)
Severity: Critical
date: 2026-06-04
Prediction: 2026-06-11
What Undercode Say
Analytics: The root cause is a classic TOCTOU issue in the outbound request validation flow. The validation logic resolves and checks the hostname but fails to enforce that the same resolved IP is used for the actual connection. This allows an attacker to exploit the separate DNS resolution performed by `node-fetch` to bypass the blacklist. The vulnerability is particularly dangerous because it enables non-blind SSRF, allowing direct exfiltration of internal service responses.
Bash Commands and Codes:
- Setup a local HTTP listener to simulate an internal service:
python3 -m http.server 8080 --bind 127.0.0.1
2. Example of a DNS rebinding hostname:
7f000001.cb007264.rbndr.us
This hostname rotates between `127.0.0.1` and a public IP like 203.0.113.100.
3. Vulnerable Code Snippet (from `packages/backend-core/src/utils/outboundFetch.ts`):
async function throwIfUnsafe(url: string): Promise<void> {
const parsed = parseUrl(url)
if (await isBlacklisted(parsed.hostname)) {
throw new Error("URL is blocked or could not be resolved safely.")
}
}
for (let redirects = 0; redirects <= MAX_REDIRECTS; redirects++) {
await throwIfUnsafe(nextUrl)
const response = await fetchFn(nextUrl, nextRequest)
// ...
}
Exploit
- Log into Budibase with a user that has automation permissions.
- Create a new automation and add an “Outgoing Webhook” step.
- In the webhook configuration, set the URL to a DNS rebinding domain you control, such as
http://<rebinding-domain>:8080/. - Ensure your authoritative DNS server for this domain is configured to return a public IP address (e.g.,
203.0.113.100) for the first query (validation) and a private/internal IP address (e.g.,127.0.0.1) for the second query (the actual `node-fetch` request).
5. Trigger the automation.
- The `throwIfUnsafe` function will resolve the hostname to the public IP, pass the blacklist check, and allow the request to proceed.
- The `fetchFn` function will perform a second DNS lookup, which resolves to the internal IP address (e.g.,
127.0.0.1). - The Budibase server will establish a connection to the internal service (e.g.,
127.0.0.1:8080) and return the response body directly in the automation output.
Protection
- Immediate Upgrade: The primary and most effective protection is to upgrade to a patched version of Budibase. This vulnerability is fixed in version 3.34.8 or later.
- Code-Level Fix: The fix involves modifying the outbound fetch logic to pin the resolved IP address to the connection, preventing a second DNS lookup. This can be achieved by using a custom `http.Agent` / `https.Agent` that performs the DNS resolution and dialing once, or by setting `redirect: “manual”` and re-checking the blacklist on every redirect hop, as implemented in the `fetchWithBlacklist` function.
- Network Controls: As a defense-in-depth measure, restrict outbound network access from the Budibase host at the firewall or network level to prevent connections to internal IP ranges (RFC1918, loopback, cloud metadata) even if an SSRF bypass occurs.
Impact
- Non-Blind Read-SSRF: Attackers can read the response from any internal service reachable from the Budibase host.
- Access to Sensitive Internal Services: This includes loopback services (
127.0.0.1), services on RFC1918 private IP ranges, internal Kubernetes or VPC services, and cloud metadata endpoints (169.254.169.254). - Credential Theft: On cloud deployments without IMDSv2 enforcement, attackers can access `http://169.254.169.254/latest/meta-data/iam/security-credentials/` to steal temporary IAM credentials.
- Cross-Tenant Access: In multi-tenant hosted deployments, this vulnerability could potentially be used to access shared internal infrastructure, leading to cross-tenant data breaches.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
