What is the CVSS score of EUVD-2026-32587?

EUVD-2026-32587 has a CVSS 3.1 base score of 8.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N. EPSS exploitation probability: 0.0%.

Which versions of Budibase are affected by EUVD-2026-32587?

Budibase versions prior to 3.39.0 contain a server-side request forgery vulnerability that allows builder-level users to redirect the application to send arbitrary requests to internal systems and…. A patch is available.

Is there a public PoC exploit available for EUVD-2026-32587?

Yes, a public proof-of-concept exploit is available for EUVD-2026-32587. Prioritise patching immediately. EPSS: 0.0%.

How to fix or mitigate EUVD-2026-32587?

Within 24 hours: Identify all Budibase deployments and inventory current versions; consider restricting builder-role access if feasible. Within 7 days: Upgrade all affected instances to Budibase 3.39.0 or later. Within 30 days: Audit builder-level role assignments and implement least-privilege access controls.

Budibase EUVD-2026-32587

| CVE-2026-48153 HIGH

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

2026-05-27 security-advisories@github.com

GHSA-4q6h-8p4v-67vq

SSRF

8.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.5 HIGH

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

May 27, 2026 - 19:54 vuln.today

Patch available

May 27, 2026 - 19:46 EUVD

DescriptionGitHub Advisory

Budibase is an open-source low-code platform. Prior to 3.39.0, fetchToken in the OAuth2 SDK makes a POST to a builder-supplied URL with plain node-fetch, skipping the blacklist.isBlacklisted check that every other outbound fetch path in the codebase uses. The Joi schema for the OAuth2 URL has no scheme or host restriction. This vulnerability is fixed in 3.39.0.

AnalysisAI

Server-side request forgery in Budibase before 3.39.0 lets a builder-level user coerce the server into sending POST requests to arbitrary internal or external destinations. The flaw lives in the OAuth2 SDK's fetchToken function, which issues outbound requests via plain node-fetch and bypasses the blacklist.isBlacklisted guard that every other outbound path enforces, while the Joi validation on the OAuth2 token URL imposes no scheme or host restriction. No public exploit identified at time of analysis, and the issue is fixed in 3.39.0.

Technical ContextAI

Budibase is an open-source low-code application platform where users with the 'builder' role configure data sources and integrations, including OAuth2 connections. The vulnerability is a classic CWE-918 (SSRF): the OAuth2 token-exchange routine (fetchToken) takes a builder-supplied token endpoint URL and dispatches a POST to it using a raw node-fetch call. Elsewhere in the codebase, outbound requests are funneled through a blacklist.isBlacklisted check designed to reject requests to internal/metadata addresses (e.g., link-local 169.254.169.254, RFC1918 ranges, localhost), but this code path skips that control entirely. Compounding the issue, the Joi input schema validating the OAuth2 URL enforces neither an allowed scheme (so http/non-https targets pass) nor a host allowlist, so any attacker-controlled host or IP is accepted as the request target.

RemediationAI

Upgrade to Budibase 3.39.0 or later, which routes the OAuth2 fetchToken path through the blacklist.isBlacklisted check and is the vendor-released patch for this issue (Vendor-released patch: 3.39.0; see GHSA-4q6h-8p4v-67vq). Where immediate upgrade is not possible, reduce exposure by restricting who holds the builder role so untrusted users cannot configure OAuth2 data sources (trade-off: limits legitimate low-code development), and place the Budibase server behind network egress controls - deny outbound access from the app server to internal/metadata ranges such as 169.254.169.254, 127.0.0.0/8, and RFC1918 networks (trade-off: may break legitimate internal integrations that depend on those targets). On cloud hosts, enforcing IMDSv2 mitigates metadata-credential theft via this SSRF without affecting application functionality.