GHSA-xcx6-4f2g-hhgx
HIGHGHSA-xcx6-4f2g-hhgx is a high-severity (CVSS 7.7) CWE-863 vulnerability in @budibase/server. O3 Security confirms whether GHSA-xcx6-4f2g-hhgx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Budibase: S3 presigned URL endpoint authorization regression in v3.39.4 allows BASIC users to obtain S3 PutObject presigned URLs
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-xcx6-4f2g-hhgx.
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
Impact
In Budibase v3.39.4, a regression in the authorization level for the S3 attachment upload endpoint allows any BASIC app user to obtain S3 PutObject presigned URLs. The endpoint uses TABLE/WRITE permission level instead of the intended BUILDER level defined in v3.39.3. Additionally, the controller does not pin the target bucket to the datasource's configured bucket, allowing writes to any S3 bucket the stored IAM credentials can access.
Reproduction
- As a BASIC app user, discover or obtain a valid S3 datasource ID within the app
- Send a POST request:
POST /api/attachments/<datasourceId>/url
Content-Type: application/json
x-budibase-app-id: <appId>
{"bucket": "target-bucket", "key": "malicious-file.html"}
- The response contains a valid S3 PutObject presigned URL
- Use the presigned URL to upload arbitrary content to any writable S3 bucket in the IAM credential scope
Root Cause
The /api/attachments/:datasourceId/url route was changed from authorized(BUILDER) in v3.39.3 to authorized(PermissionType.TABLE, PermissionLevel.WRITE) in v3.39.4. BASIC users have TABLE/WRITE permissions by default, so they can call this endpoint. The controller at packages/server/src/api/controllers/static/index.ts:614-632 accepts the bucket parameter directly from the request body and passes it to getSignedUrl without validating against the datasource's configured bucket.
Evidence
The test suite at packages/server/src/api/routes/tests/static.spec.ts:218-235 confirms this behavior. The test authenticates as a BASIC role user and successfully generates a signed upload URL, verifying HTTP 200 and a defined res.body.signedUrl.
Remediation
- Restore the
authorized(BUILDER)middleware on the route - Add
paramResource("datasourceId")to ensure the datasource belongs to the caller's app - Pin the S3 bucket to
datasource.config.bucketin the controller, ignoring the caller-supplied bucket value
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @budibase/server | all versions | No fix |
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.
Remediation status
No patched version of @budibase/server has shipped for GHSA-xcx6-4f2g-hhgx yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
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-xcx6-4f2g-hhgx 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-xcx6-4f2g-hhgx. 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-xcx6-4f2g-hhgx in your dependencies?
O3 detects GHSA-xcx6-4f2g-hhgx across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.