Server: Budibase: Email Change IDOR via POST /api/v2/email allows full Account Takeover (accountId not validated against session) (CVE-2026-73303)
## Summary `POST /api/v2/email` on the account portal (`account.budibase.app`) starts an email-change workflow using a client-supplied `accountId` that is **not validated against the authenticated session**. A logged-in attacker supplies a victim's `accountId` and an email address they control; the verification code is delivered to the attacker's address, and completing the workflow changes the **victim's** account email. The attacker then password-resets the victim's account through the controlled address and logs in — full account takeover with no victim interaction. ## Vulnerability Details The endpoint session-checks the `currentEmail` field (a mismatch returns 403), but it does not enforce `body.accountId === session.accountId`. The account-portal frontend only ever submits the logged-in user's own accountId, so in normal use the two always match — the server simply trusts the body value. An attacker who has a victim's `accountId` can point the workflow at the victim's account while passing their own `currentEmail` to clear the session check. This is more powerful than a direct password reset: `PUT /api/v2/auth/password {email}` already exists and is gated only on knowing the victim's email, but the reset link is sent to the address on the account — the victim's inbox, which the attacker does not control. This IDOR moves the victim's email to an attacker-controlled inbox first, so the attacker receives the reset link and sets a password they know. **accountId obtainability.** We checked every endpoint reachable from a non-admin free-tier account — `GET /api/global/users` (no UUID in any user record), `GET /api/global/auditlogs/search` (no accountId field), `GET /api/global/users/invites` (code + email + name only), `GET /api/v2/tenant` (one tenant-internal UUID, not a user accountId), the account-portal frontend (passes the session's own accountId only), and all unauthenticated endpoints — and the victim's `accountId` was not present in any of them. The attacker must obtain the UUID through some channel other than the normal API surface (support channel, screenshot, a leak, prior compromise, etc.). ## Steps to Reproduce **Setup:** Two account-portal accounts at `https://account.budibase.app` — Account A (attacker) and Account B (victim). From Account B's session, `GET /api/auth/self` returns `account.accountId` — this is the value the attacker needs. 1. **Start the email-change workflow pointed at the victim's accountId, newEmail = attacker-controlled.** ```http POST /api/v2/email HTTP/1.1 Host: account.budibase.app Content-Type: application/json Cookie: budibase:auth=<ACCOUNT_A_JWT> {"currentEmail":"<ACCOUNT_A_EMAIL>","newEmail":"[email protected]","accountId":"<VICTIM_ACCOUNT_ID>"} ``` Response: `201 Created`, sets `budibase:change_email:correlationkey` (HttpOnly), `:instancekey`, `:status`, `:newemail` cookies. The workflow started against the victim's accountId even though the caller is Account A. 2. **Complete the change with the code from the attacker-controlled inbox (or read directly from the `correlationkey` cookie set in step 1).** ```http POST /api/v2/email/verification HTTP/1.1 Host: account.budibase.app Content-Type: application/json Cookie: budibase:auth=<ACCOUNT_A_JWT>; budibase:change_email:correlationkey=<CODE>; budibase:change_email:instancekey=<KEY> {"verificationCode":"<code>","processInstanceKey":"<key>"} ``` Response: `200 OK`. The victim's account email is now `[email protected]`. 3. **Confirm the change hit the victim, not the caller (false-positive control).** - Account A (caller) still logs in with its own original email — 200, unchanged. - Account B's (victim) original email is now rejected — 403, locked out. - `[email protected]` now logs into the victim's account — 200. 4. **Take over the account.** ```http PUT /api/v2/auth/password HTTP/1.1 Host: account.budibase.app Content-Type: application/json {"email":"[email protected]"} ``` Response: `202 Accepted`, reset link delivered to the attacker's own inbox. Complete the reset with `PUT /api/v2/auth/password/verification`, then log in as the victim with the attacker-chosen password. `GET /api/auth/self` afterward returns the victim's real `accountId` and `tenantId` — full account takeover, confirmed via a genuinely separate account/tenant (not a same-account self-test). ## Impact An authenticated account-portal user who obtains a victim's `accountId` (out-of-band — it is not exposed anywhere in the normal cross-user API surface we could find) can take over that victim's account: rewrite the login email to an attacker address, set a new password, and access the victim's tenants, apps, and stored datasource credentials (REST/SQL/S3 auth). The victim is locked out of their own account. Every step from the initial IDOR write to full login-as-victim is deterministic and 100% reliable once the accountId is known — no additional vulnerability or guessing
AI Analysis
Technical Summary
The Budibase server's email change workflow at POST /api/v2/email trusts a client-supplied accountId without verifying it matches the authenticated session's accountId. An attacker logged into their own account can supply a victim's accountId and an attacker-controlled email address to initiate an email change for the victim's account. The verification code is sent to the attacker-controlled email, allowing the attacker to complete the workflow and change the victim's email. Subsequently, the attacker uses the password reset endpoint to set a new password via the attacker-controlled email, achieving full account takeover. The vulnerability arises because the server only checks that the currentEmail matches the session but does not validate the accountId parameter against the session. The victim's accountId is not exposed in any public or authenticated API endpoints, requiring the attacker to obtain it out-of-band. This flaw is classified as CWE-639 (Authorization Bypass Through User-Controlled Key).
Potential Impact
An authenticated attacker who obtains a victim's accountId can fully take over the victim's Budibase account by changing the victim's login email to an attacker-controlled address and resetting the password. The attacker gains access to all tenant data, applications, and stored credentials associated with the victim's account. The victim is locked out of their account. The attack requires no victim interaction beyond the attacker having the victim's accountId, which is not exposed via normal API calls and must be obtained through other means.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, restrict access to accountId values and monitor for suspicious email change requests. Avoid sharing accountId values externally and consider additional verification steps for email change workflows. Do not rely solely on client-supplied accountId values for authorization checks.
Server: Budibase: Email Change IDOR via POST /api/v2/email allows full Account Takeover (accountId not validated against session) (CVE-2026-73303)
Description
## Summary `POST /api/v2/email` on the account portal (`account.budibase.app`) starts an email-change workflow using a client-supplied `accountId` that is **not validated against the authenticated session**. A logged-in attacker supplies a victim's `accountId` and an email address they control; the verification code is delivered to the attacker's address, and completing the workflow changes the **victim's** account email. The attacker then password-resets the victim's account through the controlled address and logs in — full account takeover with no victim interaction. ## Vulnerability Details The endpoint session-checks the `currentEmail` field (a mismatch returns 403), but it does not enforce `body.accountId === session.accountId`. The account-portal frontend only ever submits the logged-in user's own accountId, so in normal use the two always match — the server simply trusts the body value. An attacker who has a victim's `accountId` can point the workflow at the victim's account while passing their own `currentEmail` to clear the session check. This is more powerful than a direct password reset: `PUT /api/v2/auth/password {email}` already exists and is gated only on knowing the victim's email, but the reset link is sent to the address on the account — the victim's inbox, which the attacker does not control. This IDOR moves the victim's email to an attacker-controlled inbox first, so the attacker receives the reset link and sets a password they know. **accountId obtainability.** We checked every endpoint reachable from a non-admin free-tier account — `GET /api/global/users` (no UUID in any user record), `GET /api/global/auditlogs/search` (no accountId field), `GET /api/global/users/invites` (code + email + name only), `GET /api/v2/tenant` (one tenant-internal UUID, not a user accountId), the account-portal frontend (passes the session's own accountId only), and all unauthenticated endpoints — and the victim's `accountId` was not present in any of them. The attacker must obtain the UUID through some channel other than the normal API surface (support channel, screenshot, a leak, prior compromise, etc.). ## Steps to Reproduce **Setup:** Two account-portal accounts at `https://account.budibase.app` — Account A (attacker) and Account B (victim). From Account B's session, `GET /api/auth/self` returns `account.accountId` — this is the value the attacker needs. 1. **Start the email-change workflow pointed at the victim's accountId, newEmail = attacker-controlled.** ```http POST /api/v2/email HTTP/1.1 Host: account.budibase.app Content-Type: application/json Cookie: budibase:auth=<ACCOUNT_A_JWT> {"currentEmail":"<ACCOUNT_A_EMAIL>","newEmail":"[email protected]","accountId":"<VICTIM_ACCOUNT_ID>"} ``` Response: `201 Created`, sets `budibase:change_email:correlationkey` (HttpOnly), `:instancekey`, `:status`, `:newemail` cookies. The workflow started against the victim's accountId even though the caller is Account A. 2. **Complete the change with the code from the attacker-controlled inbox (or read directly from the `correlationkey` cookie set in step 1).** ```http POST /api/v2/email/verification HTTP/1.1 Host: account.budibase.app Content-Type: application/json Cookie: budibase:auth=<ACCOUNT_A_JWT>; budibase:change_email:correlationkey=<CODE>; budibase:change_email:instancekey=<KEY> {"verificationCode":"<code>","processInstanceKey":"<key>"} ``` Response: `200 OK`. The victim's account email is now `[email protected]`. 3. **Confirm the change hit the victim, not the caller (false-positive control).** - Account A (caller) still logs in with its own original email — 200, unchanged. - Account B's (victim) original email is now rejected — 403, locked out. - `[email protected]` now logs into the victim's account — 200. 4. **Take over the account.** ```http PUT /api/v2/auth/password HTTP/1.1 Host: account.budibase.app Content-Type: application/json {"email":"[email protected]"} ``` Response: `202 Accepted`, reset link delivered to the attacker's own inbox. Complete the reset with `PUT /api/v2/auth/password/verification`, then log in as the victim with the attacker-chosen password. `GET /api/auth/self` afterward returns the victim's real `accountId` and `tenantId` — full account takeover, confirmed via a genuinely separate account/tenant (not a same-account self-test). ## Impact An authenticated account-portal user who obtains a victim's `accountId` (out-of-band — it is not exposed anywhere in the normal cross-user API surface we could find) can take over that victim's account: rewrite the login email to an attacker address, set a new password, and access the victim's tenants, apps, and stored datasource credentials (REST/SQL/S3 auth). The victim is locked out of their own account. Every step from the initial IDOR write to full login-as-victim is deterministic and 100% reliable once the accountId is known — no additional vulnerability or guessing
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Budibase server's email change workflow at POST /api/v2/email trusts a client-supplied accountId without verifying it matches the authenticated session's accountId. An attacker logged into their own account can supply a victim's accountId and an attacker-controlled email address to initiate an email change for the victim's account. The verification code is sent to the attacker-controlled email, allowing the attacker to complete the workflow and change the victim's email. Subsequently, the attacker uses the password reset endpoint to set a new password via the attacker-controlled email, achieving full account takeover. The vulnerability arises because the server only checks that the currentEmail matches the session but does not validate the accountId parameter against the session. The victim's accountId is not exposed in any public or authenticated API endpoints, requiring the attacker to obtain it out-of-band. This flaw is classified as CWE-639 (Authorization Bypass Through User-Controlled Key).
Potential Impact
An authenticated attacker who obtains a victim's accountId can fully take over the victim's Budibase account by changing the victim's login email to an attacker-controlled address and resetting the password. The attacker gains access to all tenant data, applications, and stored credentials associated with the victim's account. The victim is locked out of their account. The attack requires no victim interaction beyond the attacker having the victim's accountId, which is not exposed via normal API calls and must be obtained through other means.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, restrict access to accountId values and monitor for suspicious email change requests. Avoid sharing accountId values externally and consider additional verification steps for email change workflows. Do not rely solely on client-supplied accountId values for authorization checks.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-c8vc-7pv3-g98p
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["npm"]
- Database Specific Severity
- HIGH
- Cvss Version
- null
Threat ID: 6a6542309c2644c7f808a757
Added to database: 07/25/2026, 23:09:36 UTC
Last enriched: 07/25/2026, 23:57:41 UTC
Last updated: 09/05/2026, 09:26:53 UTC
Views: 107
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.