Vulnerability-Lookup

CVE-2026-73303 (GCVE-0-2026-73303)

Vulnerability from cvelistv5 – Published: 2026-08-12 18:51 – Updated: 2026-08-12 22:11

Title

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

Summary

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.

Severity

8.2 (High)


                        
                          CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-12 22:08 UTC

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7761 records in the last 180 days details

References

2 references

URL	Tags
https://github.com/Budibase/budibase/security/adv…	x_refsource_CONFIRM
https://github.com/Budibase/budibase/releases/tag…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version	CPE status
Budibase	budibase	Affected: < 3.40.0	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-73303",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-12T22:08:59.202420Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-12T22:11:41.829Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "budibase",
          "vendor": "Budibase",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.40.0"
            }
          ]
        }
      ],
      "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "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"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-12T18:51:38.748Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p"
        },
        {
          "name": "https://github.com/Budibase/budibase/releases/tag/3.40.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Budibase/budibase/releases/tag/3.40.0"
        }
      ],
      "source": {
        "advisory": "GHSA-c8vc-7pv3-g98p",
        "discovery": "UNKNOWN"
      },
      "title": "Budibase: Email Change IDOR via POST /api/v2/email allows full Account Takeover (accountId not validated against session)"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-73303",
    "datePublished": "2026-08-12T18:51:38.748Z",
    "dateReserved": "2026-08-11T19:42:11.451Z",
    "dateUpdated": "2026-08-12T22:11:41.829Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-73303",
      "date": "2026-10-24",
      "epss": "0.00308",
      "percentile": "0.22462"
    },
    "nvd": {
      "cve": {
        "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"
          }
        ]
      }
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-73303",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-08-12T22:08:59.202420Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-08-12T22:09:00.758Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "budibase",
              "vendor": "Budibase",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003c 3.40.0"
                }
              ]
            }
          ],
          "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."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "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"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-639",
                  "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-08-12T18:51:38.748Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p"
            },
            {
              "name": "https://github.com/Budibase/budibase/releases/tag/3.40.0",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/Budibase/budibase/releases/tag/3.40.0"
            }
          ],
          "source": {
            "advisory": "GHSA-c8vc-7pv3-g98p",
            "discovery": "UNKNOWN"
          },
          "title": "Budibase: Email Change IDOR via POST /api/v2/email allows full Account Takeover (accountId not validated against session)"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2026-73303",
        "datePublished": "2026-08-12T18:51:38.748Z",
        "dateReserved": "2026-08-11T19:42:11.451Z",
        "dateUpdated": "2026-08-12T22:11:41.829Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-73303

Vulnerability from fkie_nvd - Published: 2026-08-12 20:17 - Updated: 2026-09-08 20:56

Severity

8.2 (High) - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/Budibase/budibase/releases/tag/3.40.0
	security-advisories@github.com	https://github.com/Budibase/budibase/security/advisories/GHSA-c8vc-7pv3-g98p

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "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"
    }
  ]
}

GHSA-C8VC-7PV3-G98P

Vulnerability from github – Published: 2026-07-24 21:14 – Updated: 2026-08-12 18:56

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": [
    "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)"
}

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-73303 (GCVE-0-2026-73303)

FKIE_CVE-2026-73303

GHSA-C8VC-7PV3-G98P

Summary

Vulnerability Details

Steps to Reproduce

Impact

Remediation

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour