Vulnerability Database

363,159

Total vulnerabilities in the database

Budibase: S3 presigned URL endpoint authorization regression in v3.39.4 allows BASIC users to obtain S3 PutObject presigned URLs — @budibase / server

Incorrect Authorization

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

  1. As a BASIC app user, discover or obtain a valid S3 datasource ID within the app
  2. 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"}
  1. The response contains a valid S3 PutObject presigned URL
  2. 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

  1. Restore the authorized(BUILDER) middleware on the route
  2. Add paramResource("datasourceId") to ensure the datasource belongs to the caller's app
  3. Pin the S3 bucket to datasource.config.bucket in the controller, ignoring the caller-supplied bucket value
  • Published: Jul 24, 2026
  • Updated: Jul 25, 2026
  • GHSA: GHSA-xcx6-4f2g-hhgx
  • Severity: High
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: High
  • Score: 7.7
  • AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

CWEs:

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.