Durante anos, HTML dentro de e mails foi tratado como aquele parente complicado que todo mundo sabe que precisa vigiar. Scripts são bloqueados, elementos perigosos são removidos e sanitizadores tentam impedir que uma mensagem faça algo além de aparecer na tela.
O problema é que o CSS também merece atenção.
Continua depois da publicidade
Uma pesquisa apresentada por Gareth Heyes, pesquisador da PortSwigger, na Black Hat USA 2026 mostrou diferentes maneiras de transformar CSS e HTML permitidos dentro de mensagens em mecanismos capazes de ultrapassar os limites do próprio e mail.
Os testes envolveram Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail e AOL Mail. Dependendo da combinação entre serviço, navegador e técnica utilizada, os experimentos permitiram falsificar interfaces, interferir em ações do usuário, extrair tokens, comprometer contas de serviços externos e até capturar senhas.
Antes de imaginar alguém roubando milhões de contas com uma folha de estilos, existe uma ressalva importante. O trabalho apresenta provas de conceito conduzidas em ambiente de pesquisa. O estudo não afirma que essas técnicas tenham sido usadas em ataques maliciosos no mundo real.
Ainda assim, a pesquisa expõe um problema interessante e um tanto desconfortável: conteúdo não confiável recebido por e mail pode acabar influenciando uma interface que o usuário considera confiável.
Quando o CSS deixa de cuidar apenas da aparência
A pesquisa, chamada “CSS: the bomb inside your inbox”, parte de uma questão relativamente simples. Serviços de webmail precisam receber HTML criado por terceiros e exibi lo dentro de aplicações que também contêm informações sensíveis, botões, menus e sessões autenticadas.
Para impedir abusos, essas plataformas utilizam sanitizadores. O conteúdo recebido é analisado e elementos considerados perigosos são removidos ou modificados antes da renderização.
Só que navegador, sanitizador e aplicação nem sempre interpretam o mesmo conteúdo exatamente da mesma maneira.
Heyes explorou justamente essas diferenças. Em alguns casos, elementos HTML e propriedades CSS já permitidos eram suficientes para produzir comportamentos inesperados. Em outros, a técnica consistia em fazer o sanitizador considerar determinado conteúdo seguro para que, posteriormente, o navegador ou o próprio código da aplicação o transformasse em algo diferente.
É aí que uma mensagem deixa de ser apenas uma mensagem.
Segundo a pesquisa, a fronteira entre o conteúdo recebido e a interface confiável do webmail pode ser atravessada quando essas diferenças de interpretação são combinadas com recursos aparentemente legítimos do HTML e do CSS.
Outlook mostra até onde esse problema pode chegar
Um dos experimentos mais impactantes foi realizado contra o Outlook.
Heyes descobriu que elementos label permitidos dentro das mensagens podiam interagir com controles existentes fora da área do e mail. Em uma das demonstrações, labels conseguiam acionar componentes da própria interface do Outlook.
O pesquisador afirma que essa técnica de manipulação de labels continuava funcionando quando o trabalho foi publicado.
Mas isso era apenas uma peça do ataque.
Outro comportamento identificado estava relacionado à maneira como dados previamente sanitizados podiam ser processados posteriormente pelo JavaScript da aplicação. A combinação permitia criar novos elementos no DOM e levar CSS para fora das restrições inicialmente impostas pelo sanitizador.
Uma peculiaridade na interpretação de consultas de mídia também permitiu enganar o mecanismo de filtragem do Outlook e chegar à injeção arbitrária de CSS.
Com controle suficiente sobre a aparência da página, o pesquisador construiu uma tela que imitava a autenticação do Outlook.
E aqui a história fica particularmente interessante.
A técnica utilizava um elemento select estilizado para parecer um campo de senha. Com recursos do CSS e um comportamento específico do Firefox relacionado à seleção das opções, foi possível registrar em tempo real os caracteres escolhidos pelo usuário.
Na demonstração publicada pela PortSwigger, a vítima recebe o e mail, vê uma interface falsa de autenticação e a senha digitada pode ser capturada.
É praticamente phishing dentro da própria interface legítima.
A pesquisa confirma que o mecanismo de manipulação de labels do Outlook continuava funcionando na publicação do estudo. Entretanto, o documento não deixa claro se toda a cadeia usada na demonstração de captura da senha permanecia explorável naquele momento.
Yahoo Mail e AOL Mail entram na história por causa do copiar e colar
Outro experimento seguiu um caminho bastante diferente.
Durante os testes, os pesquisadores perceberam que conteúdo HTML presente na área de transferência podia se comportar de maneiras diferentes dependendo do navegador e do serviço de e mail.
No Yahoo Mail e no AOL Mail, utilizando Firefox, CSS colado dentro da área de composição podia permanecer ativo brevemente antes do processo de sanitização.
Essa pequena janela foi suficiente para criar uma condição de corrida.
A demonstração utilizou o sistema de login por e mail do Medium. Esse processo gera um token hexadecimal de 12 caracteres que pode ser usado na autenticação.
O cenário começa quando o atacante solicita o login utilizando o endereço da vítima. Depois, a vítima precisa copiar um conteúdo HTML preparado pelo atacante e colá lo em um rascunho no Yahoo Mail ou AOL Mail.
O CSS consegue então testar informações presentes no conteúdo e provocar requisições que revelam partes do token.
Com dados suficientes, o servidor controlado pelo atacante consegue reconstruir o código necessário para autenticação.
Não é exatamente aquele “Ctrl C, Ctrl V” inocente que todo mundo espera.
Vale reforçar que esse cenário depende de várias condições e de interação da vítima. A pesquisa demonstra a viabilidade técnica da cadeia, não uma campanha ativa explorando usuários desses serviços.
E quando a política de segurança bloqueia requisições externas?
Uma das partes mais curiosas da pesquisa tenta responder outra pergunta: o que acontece quando uma Content Security Policy impede que o CSS simplesmente envie informações para um servidor externo?
A solução encontrada foi transformar o próprio clique do usuário no mecanismo de exfiltração.
O experimento parte da existência de um token numérico exibido como texto e da possibilidade de injetar estilos na página.
Usando recursos modernos do CSS, é possível identificar quais números aparecem e quantas vezes eles estão presentes. A partir dessas informações, links incompatíveis são efetivamente removidos da área clicável enquanto o link correspondente ao conjunto correto de números passa a ocupar a página.
Quando a vítima clica, as informações são enviadas ao servidor controlado pelo pesquisador.
Ou seja, mesmo sem uma requisição automática tradicional, o navegador ainda pode ser convencido a carregar os dados para fora da aplicação por meio de uma ação aparentemente comum.
Gmail, Claude e o novo problema dos agentes de IA
A pesquisa ganha outra dimensão quando entram em cena ferramentas de inteligência artificial capazes de acessar caixas de e mail.
Heyes encontrou no Gmail uma maneira de utilizar a função image set do CSS para gerar uma requisição externa mesmo após o processo de sanitização. Segundo a publicação da PortSwigger, esse comportamento continuava funcionando quando o estudo foi divulgado.
O pesquisador então trabalhou com Pete Hendy, também da PortSwigger, para combinar a técnica com uma injeção indireta de prompt direcionada ao Cowork, da Anthropic.
O cenário utilizava o conector do Gmail. A própria documentação da Anthropic confirma que seus conectores do Google Workspace permitem ao Claude pesquisar e ler mensagens e criar rascunhos no Gmail.
Na prova de conceito, os pesquisadores utilizaram um token enviado por e mail pelo Slack como informação sensível.
O atacante primeiro prepara uma mensagem contendo instruções manipuladas. Quando a vítima solicita ao Cowork que processe os e mails, essas instruções podem influenciar o agente a localizar o código recebido e incorporá lo em um rascunho HTML.
Quando o usuário posteriormente visualiza esse rascunho, o comportamento relacionado ao image set provoca uma requisição externa que carrega o token.
Existe interação do usuário e uma cadeia específica de condições. Ainda assim, o experimento ilustra um problema que tende a aparecer cada vez mais.
Um e mail agora pode ter dois leitores: a pessoa e a inteligência artificial. E eles não necessariamente enxergam a mesma coisa.
O que o usuário vê pode ser diferente do que a IA interpreta
Essa diferença também apareceu em um experimento envolvendo Fastmail e o Atlas, navegador com recursos de IA da OpenAI.
Utilizando pseudo elementos do CSS e alterações extremamente baixas de opacidade, Heyes criou conteúdo no qual o texto percebido pela pessoa era diferente das instruções processadas pelo modelo.
A vítima via um conteúdo aparentemente comum. A IA encontrava instruções escondidas.
No cenário demonstrado, ao pedir que o Atlas traduzisse o texto visível, uma palavra específica funcionava como gatilho para as instruções ocultas. O agente então abria páginas e utilizava fragmentos das URLs para codificar informações obtidas da página, incluindo o nome da vítima.
É um exemplo bastante didático de injeção indireta de prompt combinada com conteúdo visualmente manipulado.
Há, porém, um detalhe temporal importante. A OpenAI está descontinuando o Atlas e informou oficialmente que o navegador está programado para deixar de funcionar em 9 de agosto de 2026. Os recursos de navegação agêntica estão sendo direcionados para experiências do ChatGPT e Codex.
Portanto, essa prova de conceito específica está ligada a um produto que está no fim de sua operação. O princípio demonstrado, porém, continua relevante para qualquer agente que interprete páginas ou mensagens de maneira diferente da pessoa que está olhando para a tela.
Fastmail também permitiu transformar cliques em outras ações
A pesquisa ainda apresenta uma técnica batizada de “CSS hotwiring” em testes contra o Fastmail.
A ideia é utilizar pseudo elementos do CSS para cobrir grandes áreas da interface enquanto eles permanecem associados a ações legítimas existentes na aplicação.
Na prática, o usuário acredita estar clicando em uma parte da tela, mas o clique pode acionar outro controle.
Segundo Heyes, essas ações também podem ser encadeadas. Isso permitiria transformar uma interação aparentemente banal em uma sequência de comandos dentro da interface.
O Fastmail também apareceu em testes envolvendo mutações de CSS e mecanismos de proxy para imagens. De acordo com o pesquisador, dois problemas relacionados a mutações de CSS foram corrigidos pelo serviço.
Outra técnica descrita utilizava um domínio permitido pelo proxy de imagens do Fastmail para identificar quando determinada mensagem era visualizada.
Proton Mail também apareceu nos testes
O Proton Mail foi alvo de uma técnica diferente relacionada ao proxy de imagens.
Heyes demonstrou uma forma de fazer uma imagem externa revelar o endereço IP do destinatário. Isso é particularmente relevante porque a proteção contra rastreadores do Proton Mail foi projetada justamente para impedir que remetentes utilizem imagens remotas para descobrir informações como endereço IP pessoal e momento exato de abertura.
Há um detalhe importante no próprio relato do pesquisador.
Ao testar novamente a técnica meses depois, ela deixou de funcionar. Heyes afirma acreditar que o comportamento tenha sido corrigido, embora seu relato indique que inicialmente houve divergência sobre a classificação do problema.
Portanto, não é correto apresentar essa falha específica como algo comprovadamente explorável hoje.
O problema maior está na fronteira de confiança
Talvez a conclusão mais importante da pesquisa não esteja em uma vulnerabilidade específica. Está na arquitetura.
Webmails executam uma tarefa complicada por definição: precisam pegar conteúdo HTML produzido por uma pessoa desconhecida na internet e renderizá lo dentro de uma aplicação autenticada que contém dados e controles sensíveis.
Sanitizar esse conteúdo ajuda, mas a pesquisa demonstra como diferenças entre parser, navegador, CSSOM, JavaScript e regras da própria aplicação podem criar comportamentos que não estavam previstos pelo filtro original.
É uma corrida complicada porque CSS e HTML continuam evoluindo.
Recursos novos adicionados aos navegadores podem transformar uma propriedade aparentemente inofensiva em uma nova peça para exploração. E quando agentes de IA passam a interpretar esse mesmo conteúdo, surge mais uma camada de complexidade.
O que era uma superfície de ataque entre remetente, webmail e navegador agora pode envolver também um modelo de inteligência artificial com acesso a outras ferramentas e serviços.
Como os serviços de webmail podem reduzir esse risco
A principal recomendação apresentada por Heyes é isolar rigidamente o conteúdo das mensagens.
Uma das abordagens sugeridas é renderizar e mails HTML dentro de iframes com sandbox, reduzindo a possibilidade de o conteúdo recebido interferir diretamente na interface confiável do serviço.
A pesquisa também recomenda validação rigorosa do CSS, cuidados especiais com atributos personalizados, bloqueio de elementos select e restrições a seletores capazes de reagir ao estado da interface.
Outro ponto importante é impedir que conteúdo controlado pelo remetente faça requisições arbitrárias de imagens. Mesmo proxies precisam ser cuidadosamente projetados para evitar que domínios permitidos acabem funcionando como atalhos para rastreamento ou exfiltração.
Não existe uma correção mágica porque o problema não depende de apenas uma vulnerabilidade.
Ele nasce da combinação de funcionalidades legítimas que, quando colocadas no contexto errado, começam a fazer coisas que seus desenvolvedores provavelmente não tinham em mente.
CSS nunca foi apenas decoração
A pesquisa de Gareth Heyes é um bom lembrete de como tecnologias consideradas banais podem ganhar novas capacidades conforme a web evolui.
CSS começou como uma maneira de definir cores, fontes e posicionamento. Hoje possui seletores condicionais, animações, variáveis, cálculos, carregamento de recursos, pseudo elementos e mecanismos capazes de reagir ao estado da página.
Isso não significa que abrir qualquer e mail HTML agora vai entregar sua senha para alguém.
Significa algo mais interessante para quem trabalha com segurança: assumir que CSS é inofensivo simplesmente porque não é JavaScript virou uma premissa perigosa.
O navegador não liga muito para nossas classificações confortáveis entre “conteúdo” e “código”. Ele simplesmente interpreta o que recebeu.
E, como essa pesquisa mostrou, às vezes interpreta bem mais do que gostaríamos.
