`CVE-2026-42897` no Microsoft Exchange Server local é explorada por e-mail criado para acionar XSS

Falha de spoofing com execução de JavaScript no navegador afeta instalações locais do Exchange Server quando mensagens maliciosas são abertas no Outlook Web Access sob condições específicas de interação.

Componente	Microsoft Exchange Server em instalações locais, com exposição no Outlook Web Access; Exchange Online não é afetado.
Vetor	Envio de e-mail especialmente criado para um usuário, com acionamento quando a mensagem é aberta no Outlook Web Access e determinadas condições de interação são atendidas.
Impacto	Execução de JavaScript arbitrário no contexto do navegador da vítima, levando a spoofing por falha de neutralização de entrada durante geração de página.
Prioridade	Habilitar ou validar o Exchange Emergency Mitigation Service, aplicar a mitigação por EOMT.ps1 quando necessário e priorizar servidores expostos a acesso web.
Artefatos	CVE-2026-42897, CVSS 8.1, avaliação de exploração ativa, mitigação por reescrita de URL e ferramenta EOMT.ps1.
Mitigação	Usar Exchange Emergency Mitigation Service ou executar EOMT.ps1 -CVE "CVE-2026-42897" via Exchange Management Shell elevada.

Resumo técnico

CVE-2026-42897 é uma vulnerabilidade de spoofing no Microsoft Exchange Server local, classificada com CVSS 8.1 e marcada como explorada em atividade real. A falha decorre de neutralização imprópria de entrada durante a geração de página, uma condição de cross-site scripting que permite a um atacante não autorizado executar JavaScript arbitrário no navegador da vítima. O caminho de exploração descrito envolve uma mensagem de e-mail especialmente criada, aberta por um usuário no Outlook Web Access, com dependência de condições específicas de interação para que o código seja executado no contexto da sessão web.

A superfície confirmada está restrita a versões locais do Exchange Server. Exchange Online não é afetado por essa vulnerabilidade. A diferença operacional é importante porque a exposição relevante está em servidores administrados pela própria organização, com dependência de configuração local, serviços Windows, publicação externa do Outlook Web Access, controles de borda, regras de reescrita e capacidade de aplicar mitigação por servidor. Como há exploração detectada e ainda existe dependência de mitigação temporária, a resposta deve priorizar inventário de servidores Exchange locais, validação do Exchange Emergency Mitigation Service e revisão de sinais de acesso ao OWA associados a mensagens suspeitas.

Fluxo técnico

O fluxo de ataque começa fora do servidor Exchange, por meio de entrega de e-mail para uma caixa acessada pelo Outlook Web Access. A mensagem contém conteúdo criado para atingir a falha de neutralização de entrada no momento em que o Exchange gera a página apresentada ao usuário. Quando a mensagem é renderizada no OWA e as condições de interação exigidas são atendidas, o conteúdo malicioso deixa de ser apenas dado controlado pelo remetente e passa a influenciar a página web entregue ao navegador. O resultado é execução de JavaScript no contexto da sessão do usuário, o que caracteriza uma exploração de XSS com consequência de spoofing.

O impacto real depende do contexto do navegador, da sessão autenticada e dos controles adicionais aplicados ao acesso web. A execução de JavaScript nesse contexto pode permitir manipulação visual da interface, apresentação de conteúdo enganoso e interação com elementos da página como se fossem parte legítima do OWA. O dado confirmado é spoofing, não execução remota de código no sistema operacional do servidor nem comprometimento direto do Exchange por shell. Ainda assim, por envolver uma aplicação de e-mail corporativo e uma sessão autenticada, o risco operacional é elevado para organizações que expõem OWA à internet ou permitem acesso de usuários a mensagens de remetentes externos sem controles robustos de filtragem e inspeção.

A mitigação temporária oferecida pela Microsoft usa configuração de reescrita de URL distribuída pelo Exchange Emergency Mitigation Service. Esse serviço é habilitado por padrão e aplica mitigações automaticamente quando o servidor pode receber as atualizações de mitigação. Em ambientes sem essa capacidade, incluindo restrições de isolamento ou air gap, a aplicação manual deve ser feita com a ferramenta local de mitigação do Exchange, executada em uma sessão elevada do Exchange Management Shell. A aplicação é por servidor, o que exige cuidado em ambientes com múltiplos servidores de caixa postal, balanceadores, nós híbridos ou servidores mantidos fora do fluxo padrão de atualização.

Superfície afetada

A exposição está concentrada em implantações locais do Microsoft Exchange Server que fornecem Outlook Web Access aos usuários. O componente explorado é a renderização web de conteúdo de e-mail, não o tráfego SMTP isoladamente. Isso significa que a simples entrega da mensagem não é suficiente para concluir o fluxo descrito; a mensagem precisa ser aberta no OWA e as condições de interação mencionadas no aviso precisam ocorrer. Mesmo com essa dependência, ambientes corporativos devem tratar caixas de alto valor, usuários administrativos, equipes financeiras, suporte e contas compartilhadas como alvos prioritários, porque essas contas frequentemente acessam e-mails externos e podem ter sessões web com permissões relevantes.

Exchange Online foi explicitamente excluído do escopo afetado. A ação defensiva, portanto, deve focar ativos locais, inclusive servidores publicados diretamente, servidores atrás de proxy reverso, nós internos acessíveis por VPN, ambientes híbridos que ainda mantêm OWA local e servidores que recebem tráfego web apenas para grupos específicos. A ausência de detalhes públicos sobre ator, alvo, escala e sucesso dos ataques limita a atribuição e impede inferências sobre setor ou região. A prioridade deve ser baseada na presença de Exchange local e OWA ativo, não em suposições sobre campanha.

• Servidores Microsoft Exchange Server em instalações locais com Outlook Web Access disponível para usuários.
• Usuários que abrem mensagens no OWA e interagem com conteúdo capaz de acionar a condição vulnerável.
• Ambientes onde o Exchange Emergency Mitigation Service está desabilitado, sem conectividade ou sem validação de status por servidor.
• Topologias com múltiplos servidores Exchange, nas quais a mitigação precisa ser confirmada individualmente.

Hunting e telemetria

A investigação deve partir de três fontes: tráfego web do OWA, eventos operacionais do Exchange e análise de mensagens recebidas antes e depois da data de divulgação. Como o vetor é e-mail criado para exploração, equipes de segurança devem revisar mensagens externas abertas por OWA, especialmente aquelas associadas a usuários que reportaram comportamento visual anômalo, páginas inesperadas, prompts incomuns ou redirecionamentos durante acesso ao webmail. Não há IoCs publicados no material técnico fornecido, portanto a caça não deve depender de hash, domínio ou payload específico.

Em servidores, a telemetria mais útil inclui logs de acesso HTTP do Exchange, registros de proxy reverso, eventos do IIS, informações de User-Agent, endereços IP de origem e sequência de requisições logo após a abertura de mensagens suspeitas. O objetivo é identificar padrões de renderização e interação associados a uma mensagem maliciosa, além de verificar se houve execução de conteúdo ativo em sessões de usuários. Em gateways de e-mail, a triagem deve procurar mensagens com HTML incomum, estruturas projetadas para afetar renderização, remetentes externos sem reputação adequada e conteúdo que provoque manipulação da interface do OWA.

A validação da mitigação também é parte do hunting. O Exchange Emergency Mitigation Service pode apresentar a descrição Mitigation invalid for this exchange version. mesmo quando a mitigação foi aplicada com sucesso, desde que o status apareça como Applied. Esse detalhe evita falso negativo operacional: a descrição é um problema cosmético, enquanto o campo de status determina a aplicação efetiva. Equipes devem registrar o estado por servidor, correlacionar com janelas de acesso e confirmar que todos os nós que atendem OWA receberam a regra de reescrita.

• Logs do IIS e do Exchange para acessos ao Outlook Web Access após abertura de mensagens externas suspeitas.
• Eventos e saídas do Exchange Emergency Mitigation Service indicando mitigação aplicada ou ausente por servidor.
• Mensagens HTML recebidas de remetentes externos com estrutura incomum, conteúdo ativo ou manipulação de renderização.
• Sessões de OWA com comportamento de interface incompatível com o fluxo normal de leitura de e-mail.
• Diferenças de mitigação entre servidores Exchange atrás do mesmo balanceador ou proxy reverso.

Mitigação

A primeira ação é inventariar todos os servidores Exchange locais e confirmar se o Exchange Emergency Mitigation Service está habilitado e operacional. Como a mitigação temporária é aplicada automaticamente por configuração de reescrita de URL, servidores com o serviço ativo devem ser verificados pelo status da mitigação, não apenas pela presença do serviço. Caso a descrição informe Mitigation invalid for this exchange version., mas o status esteja como Applied, a mitigação deve ser tratada como aplicada, pois o problema informado é cosmético.

Quando o serviço automático não puder ser usado, a mitigação deve ser aplicada manualmente com a versão mais recente da ferramenta Exchange on-premises Mitigation Tool, obtida em aka[.]ms/UnifiedEOMT. Para um único servidor, a execução indicada é .\EOMT.ps1 -CVE "CVE-2026-42897" em Exchange Management Shell elevada. Para múltiplos servidores, a execução indicada exclui servidores com papel Edge e aplica a mitigação aos demais com Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897". Após a execução, a equipe deve validar o status individualmente e documentar quais servidores foram cobertos.

A resposta operacional deve incluir redução de exposição até a correção permanente ficar disponível. Isso pode envolver reforço de autenticação para OWA, restrição de acesso por origem quando compatível com a operação, inspeção de e-mails HTML, revisão de regras de proxy reverso e acompanhamento de usuários que acessaram mensagens suspeitas pelo OWA. Como não há detalhes públicos sobre ator, infraestrutura, alvos ou sucesso dos ataques, a contenção deve ser orientada por telemetria local: identificar caixas que receberam mensagens suspeitas, confirmar abertura pelo OWA, revisar sessões subsequentes e remover mensagens remanescentes quando houver evidência de exploração.

• Confirmar que o Exchange Emergency Mitigation Service está habilitado e que CVE-2026-42897 aparece com status Applied nos servidores afetados.
• Executar .\EOMT.ps1 -CVE "CVE-2026-42897" em Exchange Management Shell elevada quando a mitigação automática não estiver disponível.
• Aplicar a mitigação em todos os servidores Exchange locais relevantes, não apenas no primeiro nó acessado pelo administrador.
• Revisar logs de OWA, IIS, proxy reverso e gateway de e-mail para mensagens abertas por usuários antes da mitigação.
• Acompanhar a correção permanente do fornecedor e substituir a mitigação temporária por atualização definitiva assim que ela estiver disponível.