https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 15:01:04 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-73303 <p>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.</p> <p>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.</p> https://db.gcve.eu/vuln/fkie_cve-2026-73303 https://db.gcve.eu/vuln/ghsa-c8vc-7pv3-g98p <p><strong>Affected:</strong> npm: @budibase/server</p> <p>## Summary</p> <p>`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&#39;s `accountId` and an email address they control; the verification code is delivered to the attacker&#39;s address, and completing the workflow changes the **victim&#39;s** account email. The attacker then password-resets the victim&#39;s account through the controlled address and logs in — full account takeover with no victim interaction.</p> <p>## Vulnerability Details</p> <p>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&#39;s own accountId, so in normal use the two always match — the server simply trusts the body value. An attacker who has a victim&#39;s `accountId` can point the workflow at the victim&#39;s account while passing their own `currentEmail` to clear the session check.</p> <p>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&#39;s email, but the reset link is sent to the address on the account — the victim&#39;s inbox, which the attacker does not control. This IDOR moves the victim&#39;s email to an attacker-controlled inbox first, so the attacker receives the reset link and sets a password they know.</p> <p>**accountId obtai…</p> <p><strong>Affected:</strong> npm: @budibase/server</p> <p>## Summary</p> <p>`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&#39;s `accountId` and an email address they control; the verification code is delivered to the attacker&#39;s address, and completing the workflow changes the **victim&#39;s** account email. The attacker then password-resets the victim&#39;s account through the controlled address and logs in — full account takeover with no victim interaction.</p> <p>## Vulnerability Details</p> <p>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&#39;s own accountId, so in normal use the two always match — the server simply trusts the body value. An attacker who has a victim&#39;s `accountId` can point the workflow at the victim&#39;s account while passing their own `currentEmail` to clear the session check.</p> <p>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&#39;s email, but the reset link is sent to the address on the account — the victim&#39;s inbox, which the attacker does not control. This IDOR moves the victim&#39;s email to an attacker-controlled inbox first, so the attacker receives the reset link and sets a password they know.</p> <p>**accountId obtai…</p> https://db.gcve.eu/vuln/ghsa-c8vc-7pv3-g98p