Budibase EUVD-2026-58653

The attacker must hold a BASIC user account on the target Budibase application - the lowest authenticated role available. They must know or discover a valid S3 datasource ID associated with the app (obtainable from API responses visible to BASIC users during normal platform use) and the app's x-budibase-app-id header value. The target Budibase instance must have at least one S3 datasource configured. The IAM credentials stored in that datasource must have s3:PutObject rights on the target bucket - the broader the IAM scope, the wider the attacker's reach across buckets. Exploitation is limited by the following factors: BASIC user authentication is required (anonymous exploitation is not possible), the S3 datasource must exist and be discoverable, and the achievable impact is bounded by the IAM permission scope of the stored credentials. Non-default configurations that restrict BASIC user account creation or limit S3 datasource exposure will reduce exposure.

The CVSS 4.0 score of 8.3 with vector AV:N/AC:L/AT:N/PR:L/UI:N reflects a network-accessible, low-complexity attack requiring only a BASIC user account - the lowest authenticated tier on the platform. The SI:H (subsequent system integrity: high) metric captures the key risk: attackers can write arbitrary content to S3 buckets beyond the Budibase system itself, scoped only by the IAM credentials stored in the platform. This is a concrete, high-value primitive - HTML, script, or binary files uploaded to S3 buckets could serve as a staging mechanism for phishing, malware distribution, or data tampering in downstream systems depending on how those buckets are used. There is no KEV listing and no standalone public exploit tool, reducing urgency versus an actively-exploited 0-day. However, the GHSA advisory provides a verbatim reproduction recipe, lowering the bar to exploitation to near zero for any authenticated user. EPSS data is not provided in the input. Risk is highest for Budibase deployments where BASIC user accounts are granted to untrusted or external parties and where the stored IAM credentials scope is broad - both common in multi-tenant or SaaS-style deployments. Risk is lower where BASIC access is restricted to fully trusted internal users or where IAM credentials are narrowly scoped per datasource bucket.

An external contractor with a BASIC user account on a Budibase deployment discovers a valid S3 datasource ID by enumerating application API responses or inspecting browser network traffic during normal platform use. They craft a POST request to /api/attachments/<datasourceId>/url with {'bucket': 'company-public-assets', 'key': 'malicious.html'}, receive a valid S3 PutObject presigned URL in the response, and use it to upload a credential-harvesting HTML page to the company's public-facing S3 bucket - no AWS credentials required beyond the platform's stored IAM keys. The reproduction steps are published verbatim in the GHSA advisory, requiring no exploit research.