Um e-mail não precisa de JavaScript, anexos nem macros para atacar quem o abre: basta-lhe folhas de estilo. É essa a conclusão de uma investigação apresentada esta semana no Black Hat USA 2026 pelo investigador Gareth Heyes, da PortSwigger, que analisou os principais serviços de correio eletrónico na web e mostrou como conteúdo de uma mensagem pode “sair” da janela do e-mail e interferir com a interface de confiança do próprio webmail — abrindo caminho a falsificação de ecrãs, roubo de tokens e cliques desviados para ações que o utilizador nunca pretendeu executar.
Resposta rápida: Investigação da PortSwigger apresentada no Black Hat USA 2026 demonstra que CSS considerado “seguro” em webmail como Gmail, Outlook, Fastmail, Proton Mail, Yahoo Mail e AOL Mail pode ser usado como superfície de ataque, sem JavaScript. São provas de conceito, não campanhas observadas em ambiente real. O utilizador final não pode desligar o CSS: a mitigação cabe sobretudo aos fornecedores (isolamento das mensagens, sanitização mais rigorosa e proxy de imagens). Para empresas, o essencial é reforçar MFA resistente a phishing e desconfiar de ecrãs de autenticação que apareçam “dentro” do webmail.
Uma superfície de ataque escondida à vista de todos
A apresentação, intitulada CSS: the bomb inside your inbox, teve lugar a 6 de agosto, com 40 minutos de duração, na sala South Seas CDF do Black Hat USA. O investigador explica que passou vários meses a analisar clientes de webmail como Yahoo Mail, AOL Mail, Fastmail, ProtonMail, Gmail e Outlook.
O problema de fundo é estrutural: é comum os clientes de webmail renderizarem CSS não confiável dentro de uma interface de confiança, tentando torná-lo seguro através de sanitização de CSS. Ou seja, a mensagem de um remetente desconhecido é desenhada no mesmo documento onde vivem os botões, etiquetas e menus da aplicação. Se a barreira entre os dois falhar, o conteúdo do atacante passa a influenciar aquilo que o utilizador vê e onde clica.
Quando a sanitização “limpa” o ataque para dentro
Uma das linhas mais interessantes do trabalho é a mutação de CSS. O CSSOM é a representação em memória, no browser, de todas as regras CSS e estilos computados; muitos clientes de webmail usam-no para analisar e filtrar as folhas de estilo, porque assim obtêm aquilo que o browser realmente renderizou — mas o browser pode aplicar transformações na leitura das propriedades, e CSS perfeitamente seguro acaba a transformar-se em código malicioso. No caso do Fastmail, os estilos do e-mail recebem um prefixo nos seletores, classes e ids para restringir o CSS ao elemento fornecido pelo utilizador — um mecanismo que, quando contornado, deixa de conter a mensagem.
No Outlook, a análise incidiu sobre o comportamento do sanitizador: o investigador notou o uso de DOMPurify com uma lista de permissões para atributos data-* personalizados, examinou o DOM para perceber que atributos estavam a ser usados e testou-os depois dentro do próprio e-mail. A metodologia descrita é iterativa e acessível a qualquer atacante com paciência: envia-se uma mensagem com sintaxe que o cliente possa permitir, inspeciona-se com as ferramentas de programador o que passou, transforma-se o vetor para ver se sofre mutação e repete-se até encontrar um exploit.
O browser também conta: o caso Yahoo e AOL
Um dos cenários mais didáticos envolve a cópia e colagem de conteúdo. Ao colar uma sonda em campos contenteditable — comuns em webmail — no AOL e no Yahoo! Mail, o texto da página piscou brevemente a vermelho, indicação clara de que o CSS não estava a ser corretamente sanitizado e de que existia uma condição de corrida.
O resultado varia consoante o navegador utilizado, o que raramente entra na avaliação de risco das equipas de segurança:
| Navegador | Comportamento observado com estilos colados |
|---|---|
| Chrome | Reescreve blocos style em linha para atributos style |
| Safari | Aparenta descartar os estilos |
| Firefox | Permite tags style em linha e pedidos de background-image |
O investigador descreve estas diferenças e considera o Firefox o alvo mais promissor, acrescentando que esse navegador bloqueava pedidos @import e animações, o que impede folhas de estilo importadas recursivamente e obriga a recorrer a seletores de atributo e a forçar os tokens por tentativa. A demonstração culmina na reconstrução de um token de autenticação: com o token completo, é possível iniciar sessão como a vítima no Medium, sendo que a técnica não afeta apenas esse serviço.
Assistentes de IA ligados ao correio ampliam o problema
A investigação não se limitou aos clientes de correio clássicos. Depois de abusar do HTML e CSS permitidos, o passo seguinte é contornar os sanitizadores para escapar à janela da mensagem — e, nessa fase, os alvos incluíram Fastmail, ProtonMail, Gmail, Cowork e Slack. A lógica é conhecida de quem acompanha o tema da injeção indireta de instruções: o que o humano vê e o que um modelo de linguagem lê podem ser coisas diferentes, porque o CSS controla a apresentação e não o conteúdo subjacente.
Vale a pena sublinhar o enquadramento: trata-se de investigação com provas de conceito divulgadas de forma responsável, e não de relatos de exploração maliciosa observada. Também não existem, neste caso, CVE públicos ou indicadores de comprometimento (IOC) divulgados que as equipas possam carregar em ferramentas de deteção — o valor prático está na revisão de arquitetura, não em regras de bloqueio.
O utilizador não pode desligar o CSS
Do lado das mitigações, a mensagem é desconfortável para quem gosta de listas de recomendações para o utilizador final. A responsabilidade recai sobretudo sobre as empresas, porque pouco há a fazer do lado de quem recebe a mensagem, a não ser que domine HTML e CSS: quando chega um e-mail com CSS malicioso num webmail, o destinatário está efetivamente preso. “You can’t turn off CSS”, resumiu o investigador em declarações à imprensa especializada.
As linhas de defesa apontadas são, por isso, arquiteturais:
- Isolar as mensagens com tecnologia que impeça a interferência com o resto da página e produzir uma sanitização de CSS mais eficaz, para o conteúdo não sair das fronteiras de confiança da mensagem
- Utilizar um proxy de imagens para proteger os utilizadores, reduzindo pedidos diretos a servidores de terceiros
- Para as organizações: privilegiar autenticação multifator resistente a phishing (chaves FIDO2/passkeys), reduzir a dependência de magic links e tokens enviados por e-mail, e formar os utilizadores para nunca introduzirem credenciais em formulários que surjam dentro da janela de leitura de uma mensagem
Não é a primeira vez que o CSS é levado a sério
O tema vem a ganhar tração académica. Em 2025, na conferência ACM CCS, investigadores apresentaram o trabalho Styled to Steal, onde demonstram um ataque sem scripts que extrai texto simples arbitrário de e-mails cifrados usando apenas CSS, sem JavaScript, recorrendo a funcionalidades aparentemente benignas como container queries, tipos de letra carregados de forma diferida e ligaduras contextuais, que mapeiam cada carácter num pedido de rede distinto. Segundo os autores, as conclusões conduziram a mitigações práticas no Thunderbird e à revisão do modelo de ameaças de uma grande tecnológica para passar a incluir CSS.
Porque é que isto importa em Portugal
O correio eletrónico continua a ser o principal ponto de entrada em incidentes reportados a nível nacional e europeu, e a maioria das PME portuguesas usa webmail alojado em serviços de terceiros. A conclusão operacional é simples: a segurança do inbox depende, em larga medida, de decisões técnicas tomadas pelo fornecedor. Isso desloca o foco da sensibilização para a gestão de risco de terceiros — precisamente o que o Regime Jurídico da Ciberseguranca (Decreto-Lei n.º 125/2025, que transpõe a NIS2) exige às entidades abrangidas, com obrigações de gestão de risco na cadeia de fornecimento e de notificação de incidentes ao CNCS/CERT.PT.
Há ainda uma dimensão de proteção de dados. Se um token de autenticação enviado por e-mail permitir a um terceiro assumir a identidade de um utilizador, o incidente pode configurar uma violação de dados pessoais, com deveres de avaliação e eventual notificação à CNPD nos termos do RGPD. Para os responsáveis de segurança, a recomendação prática é revisitar o modelo de ameaça do canal de e-mail: assumir que a interface do webmail é território partilhado com remetentes desconhecidos e reduzir o valor daquilo que circula na caixa de entrada.
Perguntas frequentes
Estes ataques com CSS estão a ser usados por criminosos?
Não há, até ao momento, relatos públicos de exploração maliciosa destas técnicas. O trabalho apresentado no Black Hat USA 2026 consiste em provas de conceito divulgadas por um investigador de segurança, com o objetivo de levar os fornecedores a reforçar o isolamento e a sanitização das mensagens.
Posso desativar o CSS no meu webmail para me proteger?
Não. O investigador é explícito ao afirmar que não é possível desligar o CSS num cliente de webmail. A defesa depende do fornecedor, que pode isolar as mensagens, filtrar melhor os estilos e encaminhar as imagens através de um proxy.
O que pode uma PME fazer na prática?
Reduzir o valor do que circula por e-mail: ativar MFA resistente a phishing, evitar depender de links de início de sessão enviados por correio, limitar as integrações de assistentes de IA com acesso total à caixa de entrada e formar os utilizadores para nunca introduzirem palavras-passe em ecrãs que surjam dentro da janela de leitura de uma mensagem.
Que relação tem isto com o Regime Jurídico da Ciberseguranca?
As entidades abrangidas pelo regime que transpõe a NIS2 têm de gerir o risco associado a fornecedores de serviços digitais, incluindo correio eletrónico, e de notificar incidentes relevantes ao CNCS/CERT.PT. Um comprometimento de contas por esta via pode ainda envolver deveres de notificação à CNPD ao abrigo do RGPD.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela PortSwigger Research, pela organização do Black Hat USA 2026 e por investigação académica apresentada na ACM CCS.