Description

Budibase versions before 3.40.0 contain an authorization/authentication bypass in the PUT /api/global/users/tenant/owner (changeTenantOwnerEmail) endpoint. On self-hosted instances (SELF_HOSTED or DISABLE_ACCOUNT_PORTAL set), the cloudRestricted middleware is a no-op and the route is protected only by a general authentication check, so any authenticated user — including a lowest-privilege BASIC app user — can reassign the tenant account-holder (top-privilege admin) email to an attacker-controlled address. The attacker can then use the public password-reset flow to take over the admin account, leading to full administrative access.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-13T22:17:24.893Z",
  "pubdate": "2026-08-13T22:17:24.893Z",
  "executiveSummary": "Budibase versions prior to 3.40.0 suffer from an authorization and authentication bypass vulnerability affecting the PUT /api/global/users/tenant/owner endpoint, also known by the function name changeTenantOwnerEmail. This security flaw enables any authenticated low-privilege user, such as a BASIC app user, to arbitrarily reassign the tenant account-holder and top-privilege administrator email address to an attacker-controlled endpoint. The primary impact is complete administrative account takeover and subsequent full administrative control over the affected Budibase instance. This vulnerability specifically impacts self-hosted instances operating under SELF_HOSTED or DISABLE_ACCOUNT_PORTAL deployment configurations. The risk implication is severe, as it permits lateral movement from the lowest privilege tier to the highest administrative privilege tier with minimal exploitation requirements. Attackers must first authenticate to the application with baseline user credentials, after which they can directly target the misconfigured API route. The vulnerability stems from improper middleware enforcement where cloud-restricted access controls evaluate to a no-op in specific self-hosted operational contexts.",
  "technicalDetails": "The vulnerability resides in the PUT /api/global/users/tenant/owner endpoint handling the changeTenantOwnerEmail function within Budibase versions prior to 3.40.0. The root cause of the authorization bypass is the improper conditional execution of the cloudRestricted middleware. On self-hosted instances where SELF_HOSTED or DISABLE_ACCOUNT_PORTAL environment variables are configured, the cloudRestricted middleware functions as a no-op instead of enforcing cloud-specific tenant boundaries and administrative privilege checks. Consequently, the route is insufficiently protected, relying solely on a basic, generalized authentication check rather than granular role-based access control (RBAC).\nExploitation requires network exposure to the Budibase instance and a valid low-privilege authentication session, such as credentials belonging to a lowest-privilege BASIC app user. Because the endpoint fails to validate whether the initiating user possesses global administrator privileges, any standard authenticated user can issue a crafted HTTP PUT request to the vulnerable endpoint. The request payload supplies an attacker-controlled email address to overwrite the existing tenant owner email configuration.\nThe step-by-step attack flow proceeds as follows: First, the attacker authenticates to the target Budibase instance using low-privilege credentials. Second, the attacker formulates an HTTP PUT request targeting the PUT /api/global/users/tenant/owner route, incorporating the desired attacker-controlled email address within the request parameters. Third, due to the ineffective cloudRestricted middleware on self-hosted deployments, the application processes the request past the initial general authentication layer without verifying administrative authorization. Fourth, the backend executes the changeTenantOwnerEmail function, successfully updating the tenant owner record to the attacker-supplied email address. Finally, the attacker leverages the public password-reset flow of Budibase, initiating a password recovery request for the newly reassigned administrative account, receiving the reset token at the attacker-controlled address, and completing the password reset to establish full administrative access over the platform."
}