Attack Chain

1. The attacker authenticates to Budibase as a user with the Builder role via POST /api/global/auth/default/login.
2. The server responds with a JWT and CSRF token embedded within the session.
3. The attacker extracts the CSRF token from the session.
4. The attacker crafts a malicious SVG file containing an XSS payload, such as <svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.domain)</script></svg>.
5. The attacker uploads the malicious SVG file to the /api/attachments/process endpoint using a POST request with the Content-Type set to multipart/form-data and including the CSRF token.
6. The server stores the SVG file in the object store (MinIO/S3) with the correct MIME type (image/svg+xml).
7. The server returns a JSON response containing the URL of the uploaded file, such as http://target:10000/files/signed/.../<uuid>.svg?X-Amz-....
8. An end user accesses a screen within the Budibase application that includes the URL of the uploaded SVG file, causing the browser to execute the embedded JavaScript. This results in XSS.

Impact

The vulnerability allows for persistent stored XSS on any screen displaying the attachment URL. Successful exploitation can lead to session cookie theft, resulting in full account takeover for application end-users. Furthermore, if a malicious URL is shared within the workspace, such as in a table attachment or embedded image, the XSS can fire in a builder’s session, potentially leading to workspace takeover. The number of affected users depends on the scale of the Budibase application and the visibility of the malicious attachment.

Recommendation

• Upgrade Budibase to version 3.38.2 or later to patch CVE-2026-46426.
• Deploy the Sigma rule “Detect Budibase Suspicious SVG Upload” to monitor for the upload of SVG files containing <script> tags.
• Deploy the Sigma rule “Detect Budibase Attachment Request with SVG Extension” to monitor for requests to uploaded SVG attachments.