` POST / api/ v 2 /email` no portal da conta (` account.budibase.app`) inicia um fluxo de trabalho de mudança de e- mail usando um ' accountId' fornecido pelo cliente que é ** não validado contra a sessão autenticada**. Um atacante conectado fornece o ` accountId' de uma vítima e um endereço de e- mail que controlam; o código de verificação é entregue ao endereço do atacante, e completar o fluxo de trabalho altera o e- mail da conta ** vítima**. O atacante então recoloca a conta da vítima através do endereço controlado e log- in — tomada completa da conta sem interação da vítima. ## Detalhes de vulnerabilidade. O objetivo da sessão-cheque o campo `correntEmail` (uma desconcordância retorna 403 ), mas não aplica ` body. accountId === session. accountId `. A interface porta- conta só envia o próprio accountId do usuário logado, por isso, em uso normal, os dois sempre coincidem — o servidor simplesmente confia no valor corporal. Um atacante que tenha o ` accountId` de uma vítima pode apontar o fluxo de trabalho para a conta da vítima enquanto passa seu próprio ` correntEmail` para limpar a verificação da sessão. Isto é mais poderoso do que uma senha direta reiniciada: ` PUT / api/ v 2 /auth/password {email}` já existe e só está fechado ao conhecer o e- mail da vítima, mas o link de reset é enviado para o endereço na conta — a caixa de entrada da vítima, que o atacante não controla. Este IDOR move o e- mail da vítima para uma caixa de entrada controlada pelo atacante primeiro, para que o atacante receba o link de reset e defina uma senha que eles conhecem.

**obrigabilidade do id de conta.** Verificamos todos os endpoints alcaçáveis a partir de uma conta de nível livre não-admin — `GET /api/global/users` (sem UUID em nenhum registro de usuário), `GET /api/global/auditlogs/search` (sem campo de id de conta), `GET /api/global/users/invites` (código + e-mail + apenas nome), `GET /api/v 2 / locant` (um UUID interno do inquilino, não um accountId do usuário), a frente da conta- portal (passa somente o accountId da sessão), e todos os endpoints não autenticados — e o ' accountId' da vítima não estava presente em nenhum deles. O atacante deve obter o UUID através de algum canal que não a superfície normal da API (canal de suporte, captura de tela, vazamento, compromisso anterior, etc.). ## Passos para Reprodução. ** Configuração:** Duas contas portais de contas em ` — Conta A (atacador) e Conta B (víctima). A partir da sessão da Conta B, `GET /api/ auth/ self` retorna ` account. accountId` — este é o valor que o atacante necessita. 1. **Inicie o fluxo de trabalho de mudança de e- mail apontado para o ID da conta da vítima, novoEmail = controlado pelo atacante.**.

```http POST /api/v 2 /email HTTP/ 1.1 Host: account.budibase.app Tipo de conteúdo: aplicativo/json Cookie: bubisase:auth= {"Email atual":" ","NovoEmail":"ataque controlado@exemplo.net","contaId":" "} ```. Resposta: ` 201 Criado`, define `budibase:change_email:correlationkey` (HttpSomente), `:instancekey`, `:status`, `:newemail` cookies. O fluxo de trabalho começou contra a conta da vítima, mesmo que a chamada seja a conta A.

2 **Complete a alteração com o código da caixa de entrada controlada pelo atacante (ou leia diretamente a partir do cookie `correlationkey` definido em passo 1 ).** ```http POST /api/v 2 /email/ verificação HTTP/ 1.1 Host: account.budibase.app Tipo de conteúdo: aplicativo/json Cookie: budibase:auth= ; budibase:change_email:correlationkey= ; budibase:change_email:instancekey=.

{"Código de verificação":" ","processInstanceKey":" "} ```. Resposta: ` 200 OK. O email da conta da vítima é agora `ataque- controlado@example.net`. 3. **Confirmar a mudança atingiu a vítima, não o que ligou (controle falso- positivo).**.

- A conta A (chamada) ainda faz login com o seu próprio e- mail original — 200, inalterado. - O email original da conta B (vítima) é agora rejeitado — 403, bloqueado. - `ataque- controlado@exemplo.net` agora faz login na conta da vítima — 200. 4 **Assumir a conta.**. ````http PUT / api/v 2 /auth/ senha HTTP/ 1.1 Host: account.budibase.app Tipo de conteúdo: aplicativo/json.

{"email":"ataque controlado@exemplo.net"} ```. Resposta: ` 202 Aceito`, reset link entregue para a caixa de entrada do atacante. Complete a reiniciação com o ` PUT / api/ v 2 /auth/password/ verification`, em seguida, faça login como a vítima com a senha do atacante escolhido. `GET /api/auth/ self` depois retorna os verdadeiros `contaId' e `tenantId' da vítima — tomada de conta completa, confirmada através de uma conta/ locante genuinamente separada (não um auto- teste da mesma conta). Um usuário autêntico porta-conta que obtém o ' accountId' de uma vítima (futura de banda - não está exposto em lugar algum na superfície normal da API de usuário cruzado que poderíamos encontrar) pode assumir a conta da vítima: reescrever o e-mail de login para um endereço do atacante, definir uma nova senha, e acessar os inquilinos da vítima, aplicativos e credenciais de fonte de dados armazenadas (REST/SQL/S) 3 Auth). A vítima está bloqueada por sua própria conta. Cada passo a partir da gravação inicial do IDOR para o login-como-víctima completo é determinístico e 100% confiável uma vez que o accountId é conhecido — não é necessária nenhuma vulnerabilidade adicional ou adivinhação, uma vez que a cadeia não usa nada além do fluxo de rede de senhas de stock da própria plataforma.

Valide que o ` accountId' do corpo é igual ao ` accountId' da sessão autenticada antes de iniciar ou completar o fluxo de trabalho de mudança de e- mail (a mesma verificação já aplicada ao `currentEmail'). Não confie em um ` accountId` fornecido pelo cliente para selecionar o alvo do fluxo de trabalho. Registro de aconselhamento: GHSA- c 8 vc- 7 pv 3 - g 98 p. Identificadores relacionados: CVE- 2026 - 73303.

Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 24 T 21: 14: 49.000 Z e lista a sua última modificação como 2026 - 08 - 12 T 18: 56: 54.000 Z. Severidade: ALTAMENTE. Nenhum vetor de pontuação está listado no registro.

Informações sobre software e versão afetadas: pacote npm @budibase/ server — ECOSISTEM: introduzido 0, última afetada 3.38.1. Classificação e evidência: identificadores de fraqueza CWE- 639. O registro contém 3 suporte de referências nestes tipos: WEB, PACKAGE.