CVE-2026-35219

Summary

Budibase: SSRF in Automation Steps - Webhook, Zapier, N8N, Slack, Discord Bypass IP Blacklist

Severity

high

EPSS

0.5% (p40)

CWE

CWE-918

Also known as

GHSA-5fpj-28rv-84r7

Published

2026-08-14

Updated

2026-08-14

Advisory details

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 check

packages/server/src/automations/steps/zapier.ts line 34:

response = await fetch(url, {method: "post", ...})  // No blacklist check

packages/server/src/automations/steps/n8n.ts line 53:

response = await fetch(url, request)  // No blacklist check

packages/server/src/automations/steps/slack.ts line 20:

response = await fetch(url, {method: "post", ...})  // No blacklist check

packages/server/src/automations/steps/discord.ts line 29:

response = await fetch(url, {method: "post", ...})  // No blacklist check

REST 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

1. Apply blacklist checks to ALL outbound HTTP requests, including automation steps
2. 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)
3. Use a centralized HTTP client wrapper instead of direct fetch() calls
4. SSRF protection should be on by default, not opt-in via environment variable

References

• https://github.com/advisories/GHSA-5fpj-28rv-84r7
• https://github.com/Budibase/budibase/security/advisories/GHSA-5fpj-28rv-84r7
• https://github.com/Budibase/budibase/releases/tag/3.41.3

Related advisories

• GHSA-v42f-v8xc-j435 — high · npm/@budibase/server
• GHSA-xg5g-26x8-cvf4 — high · npm/@budibase/server
• GHSA-hfhx-w8p8-4hc7 — medium · npm/@budibase/server
• GHSA-mqhr-6j6h-74p5 — critical · npm/@budibase/server
• GHSA-hp6v-6jw7-gv2f — critical · npm/@budibase/server
• GHSA-q6x4-v3qx-85qw — critical · npm/@budibase/server
• CVE-2026-54356 — high · npm/@budibase/server
• GHSA-pmpg-2mxq-6xwr — high · npm/@budibase/server

Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.

Summarize with AI

ChatGPTClaudePerplexity