Budibase: Unrestricted Upload of File with Dangerous Type

QFinch assessment

The file upload endpoint POST /api/attachments/process does not enforce active-content restrictions for authenticated users. The checks for dangerous file extensions (html, svg, js, php, etc.) are conditionally wrapped inside if (isPublicUser) or if (isPublicUser || !env.SELFHOSTED), meaning any authenticated builder can upload executable web content — SVG files with inline <script> tags, HTML pages with JavaScript, .js modules — which are then stored in the object store (MinIO/S3) with their correct MIME types (image/svg+xml, text/html, application/javascript). When the resulting signed URL is opened by any app user, the browser executes the payload. Impact is persistent stored XSS over all application end users.

Potential impact

App end users - Stored XSS on any screen containing the attachment URL. Session cookie theft → full account takeover. | Builder accounts - If malicious URL is shared within the workspace (table attachment, embedded image), XSS fires in builder's session → workspace takeover. <img width="3087" height="1489" alt="image" src="https://github.com/user-attachments/assets/b0ee0263-85de-430e-9575-88ec91eae565" /> <img width="2100" height="1016" alt="image" src="https://github.com/user-attachments/assets/5133bb1e-f637-479e-952f-14b3265129b4" /> -------- Discovered By: Abdulrahman Albatel Abdullah Alrasheed

Technical context

The vulnerability exists in a single handler function uploadFile shared by two routes, located in packages/server/src/api/controllers/static/index.ts (lines 93–179). Route definitions (packages/server/src/api/routes/static.ts): POST /api/attachments/process → authorized(BUILDER) POST /api/attachments/:tableId/upload → authorized(PermissionType.TABLE, PermissionLevel.WRITE) Both routes invoke the same uploadFile function. The second endpoint is accessible to any authenticated app user (BASIC or POWER role) who has been granted WRITE on any table — not just builders.