O recente Zero-Day no Exchange Server e a complexidade de sanitizar inputs · caioduque

Nos últimos dias (especificamente a partir do Patch Tuesday deste mês e com alertas de exploração ativa confirmados até o dia 17 de maio), um Zero-Day crítico apareceu... o CVE-2026-42897.

O problema afeta diretamente o Outlook Web Access (OWA) através de uma falha de Improper Neutralization of Input. O vetor de ataque é bem direto e nada surpreendente... um e-mail com payload malicioso é enviado para a vítima. Se ela apenas visualizar a mensagem no OWA, o código consegue escapar e executar JavaScript no contexto do navegador. Não exige clique em links ou downloads (ou seja, não necessita de interação do usuário!).

Antes de continuar... prazer, meu nome é Caio Duque! Atuo como SRE na Cloud Ace Brasil, e também sou bug hunter oficial no Discord e no Github. Durante alguns hunts recentes que tenho feito e durante os reports de vulnerabilidades, acabei notando um padrão recorrente em que nós, como desenvolvedores, tendemos a confiar bastante nos parsers e nas sanitizações automáticas dos frameworks. O problema é que em contextos complexos de renderização, como pegar um HTML de fonte externa (o e-mail) e injetar dentro de uma interface já densa (o OWA), quase sempre sobram brechas de interpretação entre o que o back-end valida e o que o front-end executa.

O impacto da mitigação atual (até agora no dia 21/05/2026)

Um ponto interessante sobre essa falha é o efeito colateral da solução temporária. Equipes de infraestrutura, como o centro de computação do Instituto de Tecnologia de Karlsruhe (KIT), reportaram publicamente nesta semana que a mitigação imposta bloqueia o JS, mas acaba quebrando funcionalidades nativas do OWA em produção:

A impressão de calendários no OWA deixa de funcionar;

Imagens inline quebram no painel de leitura (precisam ser abertas como anexo);

Calendários publicados começam a retornar erro 500.

Isso demonstra (e para muitos, revela) o quão difícil é isolar uma falha quando o componente vulnerável está fortemente integrado ao core da aplicação.

O que fica de aprendizado

Quando estamos desenvolvendo apps que consomem dados de terceiros (webhooks, APIs externas, conteúdos de e-mail), a segurança precisa de uma séria e carinhosa atenção, principalmente na validação no banco de dados. Abaixo, listarei alguns pontos de atenção:

1. Content Security Policy (CSP): Uma CSP bem configurada e restritiva é de fato um excelente ponto de partida. Não negligencie CSPs só porque podem dificultar um pouco no começo, até ajustar tudo corretamente, quebrando algumas partes da sua interface. Uma vez que você configure corretamente, se torna algo indispensável e importante. Nesse caso do Exchange, ela poderia ter impedido que scripts não assinados rodassem, mesmo que o bypass do HTML acontecesse.

2. Context-Aware Encoding: Sanitizar a entrada de dados é o básico, mas aplicar o encoding focado estritamente no contexto do output (saber exatamente se o dado vai para um atributo, uma tag ou um bloco de script) é o que realmente evita o bypass na prática.

No mais, é isso pessoal. Espero que a reflexão acima declarada possa te trazer algum aprendizado, e principalmente, ambição em aprender ainda mais.

Alguém aqui gerencia infraestrutura com Exchange e precisou aplicar essas mitigações na última semana? Ou já teve que lidar com um XSS que passou batido por um framework que, na teoria, era seguro por padrão?

Cara, achei muito interessante a forma como você explicou isso. Eu sinceramente não tinha uma noção tão clara sobre como uma simples visualização de e-mail poderia gerar uma brecha tão séria dentro do OWA, principalmente sem exigir interação do usuário. Sempre ouvi falar sobre sanitização e validação de input, mas lendo o que você escreveu deu pra entender melhor como, na prática, existem várias camadas onde o problema pode acontecer, especialmente nessa diferença entre o que o back-end considera seguro e o que o navegador realmente interpreta.

Também achei interessante a parte das mitigações quebrarem funções nativas do sistema. Isso mostra o quanto segurança e funcionalidade às vezes ficam totalmente interligadas, e como corrigir uma vulnerabilidade crítica pode acabar afetando partes importantes da aplicação.

A explicação sobre CSP e Context-Aware Encoding também me ajudou bastante a compreender por que apenas “sanitizar” não resolve tudo. Eu realmente não tinha parado pra pensar que o contexto onde o dado é renderizado muda completamente a forma como ele precisa ser tratado.

Por mais simples que seja, eu compreendi muito bem, principalmente pra quem ainda está aprendendo mais sobre segurança em aplicações web e infraestrutura. Dá pra perceber que você trouxe não só a notícia da vulnerabilidade, mas também um aprendizado técnico bem útil em cima dela.

Cada dia aprendendo mais com uma pessoa no qual quer o melhor para si mesmo e para as pessoas que querem aprender mais sobre, excelente.

O que mais me chamou atenção foi perceber que o impacto não ficou só na vulnerabilidade em si, mas também nas consequências das mitigações aplicadas. Ver funcionalidades importantes do OWA sendo afetadas, como impressão de calendários deixando de funcionar, imagens inline quebrando e até erros 500 em calendários publicados, mostra o quanto uma falha dessas consegue atingir diretamente o ambiente de produção.

Isso também deixa evidente como sistemas grandes e integrados acabam ficando extremamente sensíveis quando uma correção precisa ser aplicada às pressas por conta de exploração ativa. Em certos casos, parece até uma “troca”: você aumenta a segurança imediatamente, mas acaba sacrificando estabilidade ou usabilidade temporariamente.

Outro ponto que achei impactante foi perceber que tudo isso começou por algo aparentemente simples: a renderização de conteúdo HTML vindo de terceiros. Dá pra entender melhor agora por que vulnerabilidades envolvendo XSS e sanitização continuam sendo tão perigosas até em plataformas enormes e maduras como o Exchange.