Na Black Hat USA 2026, o pesquisador da PortSwigger Gareth Heyes apresentou uma palestra chamada “CSS: the bomb inside your inbox”, e a descoberta por trás do título é genuinamente incômoda para quem acredita que autenticação de email equivale a segurança de email. Heyes mostrou que CSS e HTML sozinhos, sem JavaScript, sem anexo e sem nenhum link malicioso, bastam para construir um keylogger funcional dentro dos principais clientes de webmail, incluindo Gmail, Outlook, Yahoo Mail, AOL Mail, Fastmail e Proton Mail. As cadeias de ataque que ele demonstrou conseguem capturar senhas, sequestrar elementos de interface confiáveis, vazar tokens de login e, em um caso, manipular uma ferramenta de IA que estava lendo o email em nome da vítima. Nada disso exige que o remetente falsifique seja o que for. Basta que o cliente de webmail do destinatário renderize o corpo da mensagem da forma como normalmente faria.
Como um menu suspenso vira um falso campo de senha
A técnica central se baseia em peculiaridades de como os navegadores implementam CSS, especificamente o comportamento de mutação, seletores de atributo e pseudo-elementos como :before, :after, :has() e :checked. Heyes usou isso para disfarçar um menu suspenso HTML comum como algo que parece, pixel por pixel, um campo de senha. O detalhe que faz o ataque capturar as teclas digitadas, e não apenas parecer convincente, é um detalhe de implementação do Firefox: o navegador reinicia seu temporizador de seleção de texto, de cerca de um segundo, toda vez que o elemento suspenso se move para fora da tela e volta. Ao disparar repetidamente esse reinício apenas com CSS, o ataque dispara uma requisição de imagem de fundo, a clássica técnica de exfiltração via CSS, uma vez a cada tecla digitada, próximo o suficiente do tempo real para o atacante reconstruir o que a vítima digitou, caractere por caractere. Nenhum script chega a rodar. O cliente de email está apenas fazendo exatamente o que as especificações de CSS dizem que ele deve fazer.
Três cadeias que realmente funcionaram
A pesquisa não foi teórica. Heyes construiu e demonstrou cadeias de ataque funcionais contra plataformas de webmail reais e atuais. Uma combinação de Outlook com Firefox falsifica uma tela de login da Microsoft convincente dentro da mensagem e captura a senha enquanto o destinatário a digita. Uma condição de corrida ao colar texto (“paste race”) no Yahoo Mail e no AOL Mail expõe um token de login de email do Medium, permitindo que o atacante entre como a vítima sem nunca tocar em uma senha. Uma cadeia do Gmail envolvendo o Cowork vai ainda mais longe, usando injeção de prompt para manipular uma ferramenta de IA que lê o email do destinatário e conseguindo que ela vaze um token do Slack após uma pequena interação do usuário. Essa última cadeia merece atenção: à medida que assistentes de IA passam a fazer parte de como as pessoas processam sua caixa de entrada, a própria caixa de entrada vira uma superfície de injeção para esses assistentes, não só para o humano que a lê.
Os patches são desiguais, e parte disso ainda funciona
A resposta dos fornecedores foi mista. O Fastmail corrigiu dois dos bugs de mutação de CSS que Heyes reportou. Um bypass de proxy que afetava o Proton Mail parou de funcionar quando ele testou novamente, sugerindo que uma correção silenciosa também chegou lá. Mas, até a publicação da pesquisa em 6 de agosto, o problema de “label-jacking” do Outlook e o bypass de image-set() do Gmail continuavam funcionando. Isso não é uma única vulnerabilidade com um único patch. É uma classe de comportamento de renderização que cada provedor de webmail implementa de um jeito ligeiramente diferente, o que significa que cada provedor está corrigindo isso, ou não, no seu próprio ritmo.
Por que o DMARC não tem nada a dizer sobre isso
O DMARC verifica exatamente uma coisa: se o domínio no cabeçalho From de uma mensagem estava autorizado a enviá-la, com base no alinhamento de SPF e DKIM. Ele não diz nada, e nunca foi projetado para dizer nada, sobre o que um cliente de webmail faz com o HTML e o CSS do corpo da mensagem depois que a entrega é aceita. Um email com uma bomba CSS pode ter origem em um domínio com política DMARC configurada em reject, assinado corretamente com DKIM, alinhado corretamente com SPF, e passar por todas essas verificações sem atrito. O ataque não precisa forjar quem enviou a mensagem. Ele precisa que o navegador do destinatário interprete um bloco de estilos, um comportamento da camada de renderização que fica inteiramente fora do que qualquer protocolo de autenticação de email inspeciona. É a mesma brecha estrutural que apareceu repetidamente este ano em phishing baseado em SVG e outras técnicas de contrabando de conteúdo: o DMARC protege o envelope, e uma parcela cada vez maior dos ataques reais acontece dentro de um conteúdo que esse envelope nunca foi projetado para examinar.
O que isso significa para o seu programa
Higienize o HTML e o CSS de entrada no gateway, não dependa apenas da filtragem do próprio provedor de webmail. A pesquisa de Heyes mostra que a higienização do lado do provedor é inconsistente e às vezes fica meses atrás da divulgação. Uma camada que você controla captura o que uma correção do lado do cliente ainda não chegou a lançar.
Trate requisições repetidas de imagem de fundo para domínios desconhecidos como um sinal, não como ruído. O mecanismo de exfiltração por trás dos ataques de bomba CSS depende de uma enxurrada de pequenas requisições de imagem. Um monitoramento de tráfego de saída que sinalize esse padrão pode pegar um ataque que a filtragem de conteúdo nunca vê.
Treine os usuários para que uma tela de login ou campo de senha renderizado dentro do corpo de um email nunca é legítimo, por mais convincente que pareça. Solicitações reais de autenticação vêm da própria interface do navegador ou de uma página carregada separadamente, nunca de dentro de uma mensagem.
Cobre dos seus fornecedores de webmail e segurança um cronograma concreto de correção, especialmente se sua organização usa Outlook ou Gmail, onde os bypasses específicos divulgados por Heyes continuavam funcionando até a publicação.
Mantenha o DMARC aplicado em reject de qualquer forma. Ele continua sendo a defesa correta contra a personificação direta de domínio, e um email com bomba CSS geralmente ainda precisa de um domínio que o atacante controle para enviar. Ele simplesmente não é, e nunca pretendeu ser, uma defesa contra o que acontece depois que o email desse domínio chega à caixa de entrada.
A conclusão
Autenticação de email e segurança de renderização resolvem problemas diferentes, e 2026 continua trazendo lembretes novos de o quanto são diferentes. Uma mensagem pode estar totalmente autenticada, perfeitamente alinhada, e ainda assim detonar no momento em que um navegador faz seu trabalho comum de interpretar CSS. A pesquisa de Heyes não significa que o DMARC falhou em nada. Significa que a exposição restante do setor migrou para a camada que o DMARC nunca foi projetado para cobrir, e fechar essa brecha agora depende de higienização de conteúdo no nível do gateway e de conscientização do usuário, lado a lado com uma autenticação forte, não da autenticação sozinha.
A Excello Mail te dá visibilidade contínua sobre o cumprimento do seu DMARC e sobre cada fonte autorizada a enviar em nome do seu domínio, para que a camada de autenticação permaneça bem protegida enquanto sua equipe foca nos riscos em nível de conteúdo que o DMARC nunca foi projetado para detectar. Cadastre-se gratuitamente na Excello Mail e veja exatamente quem está enviando emails como você, o tempo todo.