The vulnerability in Budibase 3.40.0 isn't simply that the wrong permission check was applied to an S3 endpoint—it's that the endpoint itself represents a category error. The route generates S3 presigned URLs for arbitrary buckets, which is an infrastructure-plane operation, yet it was gated with TABLE/WRITE, a data-plane permission. This matters because TABLE/WRITE semantics are designed for modifying rows in application's data layer; they should never grant access to trigger IAM-credential-backed writes against storage buckets that may serve other tenants.
The narrow version window (3.39.4 to 3.40.0) indicates this was likely introduced during a feature expansion, not as a deliberate security decision. The BUILDER permission that previously guarded this endpoint was almost certainly an artifact of the original implementation—not a threat-modeled security boundary. When someone extended the feature to BASIC users, they reached for TABLE/WRITE because it semantically matched 'user should be able to write something,' without recognizing that in this context, 'write' means 'trigger infrastructure operations' rather than 'modify rows.'
What makes this particularly severe is the output: a presigned URL is a generative credential that escapes Budibase's audit perimeter entirely. It can be forwarded to third parties, stored in logs, or posted to Slack—none of which leave a differential audit trail inside Budibase indicating unauthorized generation. In multi-tenant deployments where IAM credentials likely access cross-tenant storage, the blast radius compounds.
The deeper concern is architectural. Low-code platforms optimize for reducing friction, which creates relentless pressure to treat permission gates as obstacles rather than guards. If Budibase's permission taxonomy has no explicit concept of 'infrastructure-plane' versus 'data-plane,' every future feature expansion risks reproducing this failure. The fix requires more than reverting the route to BUILDER—it demands examining whether other infrastructure-delegating endpoints (cloud storage, external APIs, webhooks) use data-plane permissions in similar fashion, and whether the platform can enforce a mandatory distinction between these operation types at the framework level.
Audit your running instances: identify which Budibase version you deploy, verify whether S3 attachment functionality is exposed to BASIC users, and confirm that the underlying IAM role or credential scope is limited to application-specific buckets rather than broad cross-tenant access.