A InvoiceShelf lançou uma correção para a CVE-2026-55610, uma falha crítica que permitia que qualquer proprietário de uma empresa sequestrasse contas de usuários de outra empresa. A vulnerabilidade, com nota 8,7 na escala CVSS, surgiu devido à ausência de uma verificação de escopo de tenant no código Laravel do aplicativo.

Como a falha funcionava

A InvoiceShelf é uma ferramenta SaaS construída sobre o Laravel que permite às empresas gerenciar usuários, faturas e configurações a partir de um único painel. A plataforma lê um cabeçalho personalizado para identificar um tenant. Quando um Proprietário (Owner) solicita o registro de um usuário, o código verifica apenas: “O solicitante é um Proprietário de sua própria empresa?”

Ele nunca verifica se o usuário alvo pertence ao mesmo tenant. O route-model binding implícito do Laravel resolve o ID do usuário para uma linha na tabela global de usuários, e a política de autorização aprova a solicitação baseando-se apenas na função (role) do solicitante.

Um invasor poderia, portanto:

  • Fornecer qualquer ID de usuário numérico na URL da solicitação.
  • Receber o registro completo do usuário, incluindo o e-mail.
  • Realizar uma atualização que sobrescreve o e-mail e a senha da vítima e até mesmo reatribui a conta para a empresa do invasor como um super-admin.

Na prática, um Proprietário malicioso transformou uma ferramenta de gestão empresarial em uma arma universal de sequestro de contas (account takeover). Não foram necessários privilégios além de “Proprietário”.

Quem é afetado

Todos os clientes da InvoiceShelf que utilizam uma versão anterior à 2.4.1 estavam expostos. Como a falha reside no caminho principal de processamento de solicitações, qualquer tenant poderia ser alvo do Proprietário de qualquer outro tenant, independentemente do tamanho ou da postura de segurança. O impacto inclui perda de confidencialidade (endereços de e-mail) e perda de integridade (alterações de senha não autorizadas, elevação para super-admin).

A Correção

Os desenvolvedores lançaram a versão 2.4.1, adicionando uma verificação explícita de tenant antes de qualquer operação de leitura ou escrita em um registro de usuário. A correção limita o escopo da consulta ao identificador da empresa ativa, forçando o Laravel a retornar apenas as linhas que pertencem ao tenant do solicitante.

O que os desenvolvedores devem aprender

  • Nunca confie em chaves primárias globais em aplicações multi-tenant.
  • Aplique um filtro de tenant em todas as buscas no banco de dados, não apenas em ações de exclusão ou criação.
  • Faça com que as políticas de autorização validem tanto a função do ator quanto o tenant do objeto alvo.
  • Trate recursos implícitos do framework, como o route-model binding, como conveniências que podem ocultar brechas de segurança, a menos que você adicione um escopo explícito.

Olhando para o futuro

O incidente mostra um risco mais amplo para qualquer SaaS que compartilhe tabelas. Auditorias de segurança devem revisar todos os endpoints que aceitam identificadores e confirmar que o escopo de tenant é aplicado uniformemente.

Conclusão: uma única verificação de tenant ausente pode transformar uma função de usuário privilegiado em um backdoor universal. O escopo adequado não é opcional; é a base do isolamento de dados em qualquer sistema multi-tenant.