CVE-2026-54351

Budibase is an open-source low-code platform. Prior to 3.39.9, the webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in externalTrigger() allows an attacker to overwrite the internal appId property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim's workspace, granting full read/write access to the victim's database. This vulnerability is fixed in 3.39.9.

Budibase is an open-source low-code platform. Prior to 3.39.9, the webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in externalTrigger() allows an attacker to overwrite the internal appId property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim's workspace, granting full read/write access to the victim's database. This vulnerability is fixed in 3.39.9.

Summary

The webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in externalTrigger() allows an attacker to overwrite the internal appId property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim's workspace, granting full read/write access to the victim's database.

Details

The webhook trigger route is registered as a public endpoint with no authentication:

// packages/server/src/api/routes/webhook.ts:12
publicRoutes.post("/api/webhooks/trigger/:instance/:id", controller.trigger)

The controller passes the raw request body as fields alongside the server-derived appId:

// packages/server/src/api/controllers/webhook.ts:142-148
await triggers.externalTrigger(target, {
  fields: {
    ...ctx.request.body,  // attacker-controlled
    body: ctx.request.body,
  },
  appId: prodAppId,       // server-controlled
})

In externalTrigger(), for webhook-triggered automations, params.fields is spread back into params:

// packages/server/src/automations/triggers.ts:237-241
params = {
  ...params,          // appId: prodAppId (server-controlled)
  ...params.fields,   // appId: VICTIM_ID (attacker-controlled, overwrites above)
  fields: {},
}

Because params.fields is spread after params, any key in the attacker's body overwrites the corresponding property in params. An attacker including "appId": "app_VICTIM_WORKSPACE_ID" in the POST body overwrites the legitimate, server-derived appId.

The contaminated params become data.event and are queued asynchronously:

// packages/server/src/automations/triggers.ts:244,271
const data: AutomationData = { automation, event: params }
// ...
return quotas.addAction(() => automationQueue.add(data, JOB_OPTS))

The async worker uses job.data.event.appId to set the workspace context:

// packages/server/src/threads/automation.ts:917,929-930
const workspaceId = job.data.event.appId  // attacker-controlled
// ...
return await context.doInAutomationContext({
  workspaceId,  // victim's workspace
  automationId,
  task: async () => { /* automation steps run here */ }
})

The synchronous path (for webhooks with a collect step) correctly overwrites appId at triggers.ts:264:

data.event = {
  ...data.event,
  appId: context.getWorkspaceId(),  // server-controlled fix
  automation,
}

This proves the developers intended appId to be server-controlled but missed applying the same fix to the async path, which is the default for all webhooks without a collect step.

PoC

Prerequisites: Attacker has builder access to their own Budibase workspace and knows a victim workspace ID (format: app_<uuid>).

Step 1: Attacker creates an automation in their own workspace with a webhook trigger and data-exfiltration steps (e.g., Query Rows → Execute Script to send data externally).

Step 2: Attacker creates a webhook for that automation and notes the webhook URL:

POST /api/webhooks/trigger/<ATTACKER_INSTANCE>/<WEBHOOK_ID>

Step 3: Attacker triggers the webhook with the victim's workspace ID injected into the body:

curl -X POST https://budibase.example.com/api/webhooks/trigger/app_ATTACKER_ID/wh_WEBHOOK_ID \
  -H 'Content-Type: application/json' \
  -d '{"appId": "app_VICTIM_WORKSPACE_ID", "normalData": "test"}'

Expected result: The automation defined in the attacker's workspace executes in the context of the victim's workspace. All database operations (Query Rows, Create Row, Delete Row, Execute Script, etc.) operate on the victim's data.

Additional overridable fields via the same mechanism:

• timeout (automation.ts:443-444): override…

Budibase is an open-source low-code platform. Prior to 3.39.9, the webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in externalTrigger() allows an attacker to overwrite the internal appId property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim's workspace, granting full read/write access to the victim's database. This vulnerability is fixed in 3.39.9.

Budibase is an open-source low-code platform. Prior to 3.39.9, the webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in externalTrigger() allows an attacker to overwrite the internal appId property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim's workspace, granting full read/write access to the victim's database. This vulnerability is fixed in 3.39.9.

Summary

The webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in externalTrigger() allows an attacker to overwrite the internal appId property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim's workspace, granting full read/write access to the victim's database.

Details

The webhook trigger route is registered as a public endpoint with no authentication:

// packages/server/src/api/routes/webhook.ts:12
publicRoutes.post("/api/webhooks/trigger/:instance/:id", controller.trigger)

The controller passes the raw request body as fields alongside the server-derived appId:

// packages/server/src/api/controllers/webhook.ts:142-148
await triggers.externalTrigger(target, {
  fields: {
    ...ctx.request.body,  // attacker-controlled
    body: ctx.request.body,
  },
  appId: prodAppId,       // server-controlled
})

In externalTrigger(), for webhook-triggered automations, params.fields is spread back into params:

// packages/server/src/automations/triggers.ts:237-241
params = {
  ...params,          // appId: prodAppId (server-controlled)
  ...params.fields,   // appId: VICTIM_ID (attacker-controlled, overwrites above)
  fields: {},
}

Because params.fields is spread after params, any key in the attacker's body overwrites the corresponding property in params. An attacker including "appId": "app_VICTIM_WORKSPACE_ID" in the POST body overwrites the legitimate, server-derived appId.

The contaminated params become data.event and are queued asynchronously:

// packages/server/src/automations/triggers.ts:244,271
const data: AutomationData = { automation, event: params }
// ...
return quotas.addAction(() => automationQueue.add(data, JOB_OPTS))

The async worker uses job.data.event.appId to set the workspace context:

// packages/server/src/threads/automation.ts:917,929-930
const workspaceId = job.data.event.appId  // attacker-controlled
// ...
return await context.doInAutomationContext({
  workspaceId,  // victim's workspace
  automationId,
  task: async () => { /* automation steps run here */ }
})

The synchronous path (for webhooks with a collect step) correctly overwrites appId at triggers.ts:264:

data.event = {
  ...data.event,
  appId: context.getWorkspaceId(),  // server-controlled fix
  automation,
}

This proves the developers intended appId to be server-controlled but missed applying the same fix to the async path, which is the default for all webhooks without a collect step.

PoC

Prerequisites: Attacker has builder access to their own Budibase workspace and knows a victim workspace ID (format: app_<uuid>).

Step 1: Attacker creates an automation in their own workspace with a webhook trigger and data-exfiltration steps (e.g., Query Rows → Execute Script to send data externally).

Step 2: Attacker creates a webhook for that automation and notes the webhook URL:

POST /api/webhooks/trigger/<ATTACKER_INSTANCE>/<WEBHOOK_ID>

Step 3: Attacker triggers the webhook with the victim's workspace ID injected into the body:

curl -X POST https://budibase.example.com/api/webhooks/trigger/app_ATTACKER_ID/wh_WEBHOOK_ID \
  -H 'Content-Type: application/json' \
  -d '{"appId": "app_VICTIM_WORKSPACE_ID", "normalData": "test"}'

Expected result: The automation defined in the attacker's workspace executes in the context of the victim's workspace. All database operations (Query Rows, Create Row, Delete Row, Execute Script, etc.) operate on the victim's data.

Additional overridable fields via the same mechanism:

• timeout (automation.ts:443-444): override…