Exchange: uma sessão válida não autoriza acesso a todas as caixas

A Microsoft lançou atualizações fora do calendário normal para a CVE-2026-96940, uma falha de autorização no Exchange Server com CVSS 8,8 e aviso publicado em 02/10/2026.[3] O ataque exige uma conta autenticada, mas pode permitir elevação de privilégios pela rede e acesso a mensagens e anexos de outras caixas da mesma organização.[3] O ponto para quem desenvolve é simples: reconhecer a identidade não encerra a decisão sobre o que ela pode acessar.

O que muda para quem desenvolve

A notícia delimita o problema à mesma organização e afirma que não há acesso entre tenants.[3] Isso não torna o impacto interno irrelevante. Em uma aplicação própria, proponho tratar o isolamento entre usuários, equipes e recursos com a mesma seriedade do isolamento entre clientes.

A Microsoft já implantou uma correção relacionada no Exchange Online, cujos clientes não precisam agir para essa falha.[3] A atualização necessária recai sobre instalações locais afetadas: Exchange Server Subscription Edition RTM, Exchange Server 2016 CU23 e Exchange Server 2019 CU15 e CU14.[3] A matéria não fornece uma tabela dos builds corrigidos.[3]

Antes de abrir uma tarefa de mudança, portanto, descubra qual produto sustenta o serviço. Uma interface web de e-mail não é informação suficiente para concluir que se trata da infraestrutura local afetada. Para desenvolvimento, a lição é também evitar testes que validem apenas o caminho feliz de login.

Como aplicar

Em uma instalação sob responsabilidade da equipe, registre a edição, o CU instalado e o pacote de correção indicado para aquela configuração. Planeje a mudança com requisitos, janela e verificação da versão final, sem deduzir o build corrigido pelo nome do produto.

Depois, monte uma matriz de autorização em homologação com caixas sintéticas. Inclua uma conta comum, uma delegação explicitamente concedida e outra posteriormente revogada. Teste mensagens e anexos separadamente: o acesso autorizado precisa continuar funcionando; o acesso sem permissão precisa continuar negado. Não utilize mensagens reais de outras pessoas para testar a hipótese.

Para uma API própria, transforme a matriz em testes de regressão por recurso. Troque os identificadores de objetos entre duas contas de teste, confirme a negativa e observe se a resposta evita entregar conteúdo indevido. Esse é um desenho de teste recomendado, não uma afirmação sobre o mecanismo exato de exploração do Exchange.

Cuidados e limites

Até a publicação, não havia evidência de exploração em ataques reais, embora a Microsoft classificasse a exploração como mais provável.[3] Probabilidade maior justifica priorização; não comprova comprometimento.

A matéria também menciona ataques do grupo Warlock ao SharePoint como contexto, não como evidência de exploração desta CVE.[3] Misturar produtos e incidentes pode produzir um diagnóstico errado e uma resposta que não corrige o ativo certo.

Os testes funcionais propostos não substituem a atualização nem provam, sozinhos, ausência da vulnerabilidade. Use-os para detectar regressões e validar permissões esperadas. A confirmação da correção deve incluir o pacote aplicável e a versão efetivamente instalada.

Fonte

[3] Fonte: The Hacker News