CVE-2026-45717: Budibase Remote Code Execution Vulnerability

HIGH
Advisory Identifier: GHSA-44m2-crh7-f4q2
CVSS 8.8
CWE-862
Published
Advisory Summary

CVE-2026-45717 is a HIGH (CVSS 8.8) remote code execution vulnerability (CWE-862: Missing Authorization) affecting Budibase libraries in the npm ecosystem. The issue involves `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. Remediation is available by upgrading affected packages to version 3.38.1.

CVE-2026-45717 at a Glance

CVE Identifier CVE-2026-45717
GHSA Identifier GHSA-44m2-crh7-f4q2
Severity HIGH
CVSS v3.1 Base Score 8.8
CWE Classification CWE-862: Missing Authorization
Affected Product Budibase
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 8.8

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-45717

To remediate this vulnerability, upgrade all affected Budibase dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@budibase/server fixed: 3.38.1
npm install @budibase/server@3.38.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @budibase/server

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-45717, inspect your project dependencies using npm:

npm ls @budibase/server

Analyze the terminal output to locate any version of Budibase in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.38.1), your application is affected.

Note: The npm ls @budibase/server command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-862: Missing Authorization, where the product does not perform an authorization check when an actor attempts to access a resource or perform an action. In Budibase, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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 ``` ```typescript 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`: ```typescript 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 ``` ```typescript 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: ```typescript // 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/<datasource_id> HTTP/1.1 Host: target Authorization: Bearer <app-user-token> Content-Type: application/json { "config": { "host": "169.254.169.254", "port": 5432, "database": "postgres", "user": "postgres", "password": "PASSWORD_REPLACEMENT" } } ``` 3. Datasource config is persisted with `host: 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 to `169.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 ```http 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`: ```diff - 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.

CVE-2026-45717 Affected Budibase Versions

1 component(s)
Fixed Versions:
3.38.1
Product / Package Ecosystem Affected Versions Fixed Version
@budibase/server
npm
< 3.38.1
3.38.1

References

Frequently Asked Questions

What is CVE-2026-45717?
CVE-2026-45717 is a security vulnerability in Budibase involving `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 under CWE-862: Missing Authorization.
Which Budibase versions are affected?
Affected versions include releases prior to 3.38.1 across affected packages: @budibase/server.
What version fixes CVE-2026-45717?
Upgrading to 3.38.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @budibase/server affected?
Yes, @budibase/server is affected in releases prior to 3.38.1. Upgrade your dependency to 3.38.1 or later.
What is the CVSS score of CVE-2026-45717?
CVE-2026-45717 has a CVSS v3.1 base score of 8.8 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
What CWE is associated with CVE-2026-45717?
CVE-2026-45717 is classified under CWE-862: Missing Authorization (The product does not perform an authorization check when an actor attempts to access a resource or perform an action.).
How can I check npm dependencies for CVE-2026-45717?
Run the dependency tree command: 'npm ls @budibase/server'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-44m2-crh7-f4q2",
  "modified" : "2026-06-08T23:51:41Z",
  "published" : "2026-05-15T17:59:47Z",
  "aliases" : [ "CVE-2026-45717" ],
  "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\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'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.\n\n## Code evidence\n\n### Route registration — 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)   // <-- 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 → `BuiltinPermissionID.WRITE`\n- `WRITE` permission includes `PermissionImpl(PermissionType.TABLE, PermissionLevel.WRITE)`\n- `getAllowedLevels(WRITE)` returns `[WRITE, READ]`\n- Therefore `TABLE/READ` is satisfied → 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/<datasource_id> HTTP/1.1\n   Host: target\n   Authorization: Bearer <app-user-token>\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's 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/<datasource_id> 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's 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/<target_datasource_id> HTTP/1.1\nHost: <budibase-host>\nAuthorization: Bearer <basic-user-access-token>\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` — 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 — SSRF to cloud metadata or internal services |\n| Integrity | High — overwrites datasource used by all app users |\n| Availability | High — 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 — 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 — 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 — security reports via GitHub Security Advisories should receive triage within days based on historical pattern.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@budibase/server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.38.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/security/advisories/GHSA-44m2-crh7-f4q2"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-45717"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Budibase/budibase"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Budibase/budibase/releases/tag/3.38.1"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-862" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-15T17:59:47Z",
    "nvd_published_at" : "2026-05-27T18:16:25Z"
  }
}