Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable via HTTP; low-privilege authenticated user required; scope changed because SSRF pivots into cloud metadata services and internal systems outside Budibase's security domain.
Primary rating from Vendor (https://github.com/Budibase/budibase).
CVSS VectorVendor: https://github.com/Budibase/budibase
Lifecycle Timeline
6DescriptionCVE.org
Summary
Budibase automation steps (outgoing webhook, Zapier, n8n, Slack, Discord, Make.com) make server-side HTTP requests to user-provided URLs using node-fetch directly, completely bypassing the IP blacklist protection that exists in the REST API integration. Additionally, the REST API blacklist itself defaults to empty when BLACKLIST_IPS is not configured.
Vulnerable Code
Automation Steps (No Blacklist)
All automation steps use fetch() directly without any IP validation:
packages/server/src/automations/steps/outgoingWebhook.ts line 69:
const response = await fetch(url, request) // No blacklist checkpackages/server/src/automations/steps/zapier.ts line 34:
response = await fetch(url, {method: "post", ...}) // No blacklist checkpackages/server/src/automations/steps/n8n.ts line 53:
response = await fetch(url, request) // No blacklist checkpackages/server/src/automations/steps/slack.ts line 20:
response = await fetch(url, {method: "post", ...}) // No blacklist checkpackages/server/src/automations/steps/discord.ts line 29:
response = await fetch(url, {method: "post", ...}) // No blacklist checkREST API Integration (Empty Default Blacklist)
packages/server/src/integrations/rest.ts line 684:
if (await blacklist.isBlacklisted(url)) {
throw new Error("Cannot connect to URL.")
}But BLACKLIST_IPS env var defaults to undefined, so the blacklist is empty:
packages/backend-core/src/blacklist/blacklist.ts lines 39-45:
if (blackListArray?.length === 0) {
return false // Always passes when no IPs configured
}Impact
- Automation steps: ANY user can create automations with webhook/Zapier/n8n/Slack/Discord steps pointing to internal IPs. These completely bypass the blacklist module
- REST API: Even when BLACKLIST_IPS is configured, it only blocks listed IPs. Default deployments have no protection.
- Cloud metadata:
http://169.254.169.254/latest/meta-data/accessible via any automation step - Internal services: Access databases, admin panels, Kubernetes API on private IPs
Remediation
- Apply blacklist checks to ALL outbound HTTP requests, including automation steps
- Add hardcoded default private IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16)
- Use a centralized HTTP client wrapper instead of direct
fetch()calls - SSRF protection should be on by default, not opt-in via environment variable
AnalysisAI
Server-side request forgery in Budibase automation steps (all versions prior to 3.41.3) exposes internal network resources - including cloud metadata endpoints, private databases, and Kubernetes APIs - to any authenticated user with automation creation rights. Five automation step types (outgoing webhook, Zapier, n8n, Slack, Discord) invoke node-fetch directly without any IP validation, completely bypassing the blacklist module that guards only the REST API integration. A second compounding flaw causes the REST API blacklist to default to an empty allowlist when the BLACKLIST_IPS environment variable is unset, meaning default Budibase deployments carry zero SSRF protection across all outbound request vectors. No CISA KEV listing exists, but the GHSA advisory provides source-level code references that substantially document the attack surface.
Technical ContextAI
Budibase is an open-source low-code platform distributed as the npm package @budibase/server. Its automation engine supports integration steps that trigger outbound HTTP requests to external services. The vulnerable handlers - outgoingWebhook.ts:69, zapier.ts:34, n8n.ts:53, slack.ts:20, and discord.ts:29 - each call node-fetch directly with user-controlled URLs and no intermediary validation. The root cause is CWE-918 (Server-Side Request Forgery): the application fetches remote resources from user-supplied input without validating the resolved destination. By contrast, the REST API integration (rest.ts:684) does invoke the blacklist module, but that module (blacklist.ts:39-45) unconditionally returns false when blackListArray is empty - which is always the case when BLACKLIST_IPS is undefined. The Kubernetes advisory tag signals elevated risk in container environments where the Kubernetes API server (commonly at 10.96.0.1:443) and inter-pod networks are reachable from the Budibase container.
RemediationAI
Upgrade @budibase/server to version 3.41.3 or later; this is the vendor-confirmed fix, implemented in commit cc07563a6b0fc0f91c51aae295952b1295546a90 and merged via PR #19328. The patch centralizes SSRF protection so that all automation step outbound calls pass through IP validation with hardcoded default private-range blocks. For deployments that cannot immediately upgrade, set the BLACKLIST_IPS environment variable to include 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16 - but note this is only a partial mitigation because automation steps bypass the blacklist module entirely regardless of this variable. A stronger compensating control is to enforce outbound network policy at the container or firewall layer, blocking egress from the Budibase server to RFC-1918 ranges and the link-local metadata IP (169.254.169.254); the trade-off is that this may break legitimate automations if Budibase intentionally targets internal services. In AWS, enforce IMDSv2 (requiring a PUT-obtained session token) to prevent credential theft via metadata endpoint access, though SSRF to other internal resources remains exploitable without this specific protection.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-60381
GHSA-5fpj-28rv-84r7