Uma investigação apresentada na Black Hat USA 2026 mostrou que o código usado para dar estilo a um email pode, em determinadas condições, ultrapassar os limites da mensagem e interferir com a interface do serviço de correio. As provas de conceito abrangem Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail e AOL Mail, com cenários que incluem roubo de palavras-passe, fuga de tokens e manipulação de ferramentas de inteligência artificial ligadas à caixa de entrada.
O trabalho foi publicado a 6 de agosto pelo investigador Gareth Heyes, da PortSwigger. Não existem indícios divulgados de exploração destes métodos em ataques reais. Ainda assim, a investigação expõe um problema estrutural: abrir um email não executa normalmente JavaScript, mas o HTML e as folhas de estilo em cascata (CSS) permitidos pelo serviço podem continuar a interagir de formas inesperadas com o navegador e com a aplicação de webmail.
Como o CSS ultrapassa os limites do email
Os serviços de webmail usam filtros para remover elementos perigosos antes de mostrarem uma mensagem. O problema surge quando o filtro considera determinado código seguro, mas o navegador ou a própria aplicação o interpreta de outra forma. Uma regra de estilo aparentemente limitada ao corpo do email pode então afetar controlos fora da mensagem, provocar pedidos a servidores externos ou revelar informação através desses pedidos.
No Outlook aberto no Firefox, Heyes combinou vários comportamentos permitidos para apresentar um falso pedido de início de sessão da Microsoft sobre a interface verdadeira. A demonstração transformava um elemento de seleção num campo semelhante ao de uma palavra-passe e permitia capturar o valor introduzido. Não bastava apenas receber a mensagem: a vítima teria de interagir com o formulário falso, tal como acontece num ataque de phishing convencional.
O caso do Gmail foi diferente. O investigador encontrou uma forma de usar a função CSS image-set() para gerar um pedido externo apesar das proteções de imagens. Essa técnica foi combinada com uma instrução maliciosa escondida num email e com uma ferramenta de IA ligada ao Gmail; depois de interação do utilizador, a cadeia demonstrada conseguiu enviar para o exterior um token do Slack. O resultado não significa que uma mensagem comum consiga, sozinha, roubar dados de todas as contas Gmail, mas mostra como uma falha de renderização pode ganhar alcance quando o email é ligado a agentes com acesso a outros serviços.
Nem todos os problemas têm o mesmo estado
A investigação descreve várias técnicas e não uma única vulnerabilidade comum a todos os fornecedores. A Fastmail corrigiu dois problemas de mutação de CSS comunicados pelo investigador, enquanto um método para contornar o proxy de imagens do Proton Mail já não funcionava quando foi novamente testado. No momento da publicação, as demonstrações relacionadas com elementos de interface no Outlook e com image-set() no Gmail continuavam operacionais segundo a PortSwigger.
Esta diferença é importante. Não é correto concluir que qualquer email pode roubar uma palavra-passe, nem que todos os serviços permanecem vulneráveis da mesma forma. As provas de conceito dependem de combinações específicas entre o conteúdo da mensagem, o cliente de webmail, o navegador e, em alguns casos, integrações adicionais. A ausência de ataques conhecidos também não elimina o risco, mas impede tratar a investigação como prova de uma campanha em curso.
O que utilizadores e empresas devem fazer
Para o utilizador, a principal defesa continua a ser desconfiar de pedidos de autenticação que aparecem dentro da caixa de correio. Se uma mensagem ou a própria interface solicitar novamente a palavra-passe, abra o serviço diretamente numa nova janela em vez de usar o formulário apresentado. Mantenha o navegador atualizado e evite copiar conteúdo desconhecido para rascunhos, uma interação explorada noutros cenários da investigação.
Nas empresas, o risco aumenta quando o email está ligado a assistentes com acesso a Slack, documentos ou aplicações internas. Essas integrações devem usar o mínimo de permissões necessário, separar ações de leitura de operações sensíveis e exigir confirmação antes de enviar informação para endereços externos. A conclusão mais útil não é abandonar o email com HTML, mas deixar de avaliar isoladamente o filtro do correio, o navegador e os agentes de IA: uma proteção aparentemente suficiente num componente pode falhar quando os três trabalham em conjunto.
Fontes: PortSwigger Research · The Hacker News · Security Affairs