{
  "affected": [
    {
      "affectedData": [
        {
          "product": "budibase",
          "vendor": "Budibase",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.40.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Budibase is an open-source low-code platform. Prior to 3.40.0, POST /api/v2/email on account.budibase.app accepted a client-controlled accountId without binding it to the authenticated session, while checking only currentEmail. An authenticated attacker who obtains a victim account identifier can start the email-change workflow for the victim, receive and submit the verification code through POST /api/v2/email/verification, move the victim email to an attacker-controlled address, and complete a password reset as the victim. This issue is fixed in version 3.40.0."
    }
  ],
  "id": "CVE-2026-73303",
  "lastModified": "2026-09-08T20:56:50.520",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.8,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-73303",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-12T22:08:59.202420Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-12T20:17:54.133",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.40.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-639"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73303"
  ],
  "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-08-12T18:56:54Z",
  "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)"
}