Nova técnica de ataque com CSS expõe senhas, tokens e IA integrada em serviços de webmail
Uma pesquisa apresentada na conferência Black Hat USA 2026 acendeu um alerta sério para a segurança do e-mail. O estudo demonstrou que falhas na forma como grandes serviços de webmail interpretam HTML e CSS podem permitir que um simples e-mail em formato HTML seja usado como vetor para roubo de senhas, captura de tokens de autenticação e até manipulação de assistentes de inteligência artificial integrados à caixa de entrada.
Entre os serviços afetados estão plataformas amplamente utilizadas, como Microsoft Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail e AOL Mail. Em todos os casos, o ponto em comum é o processamento insuficientemente restritivo de HTML e, principalmente, de CSS – algo que, até pouco tempo atrás, era considerado relativamente seguro em comparação com JavaScript.
A pesquisa foi conduzida por Gareth Heyes, da PortSwigger, que detalhou várias cadeias de ataque em provas de conceito. Ele afirma não haver evidências de uso malicioso em larga escala até o momento, mas o fato de as técnicas e códigos de demonstração estarem publicamente disponíveis aumenta o risco de que agentes mal-intencionados passem a explorá-las.
Roubo de senha via tela falsa de login no Outlook
Em um dos cenários mais preocupantes, envolvendo o Outlook em conjunto com o navegador Firefox, Heyes mostrou como um e-mail especialmente preparado pode exibir uma falsa tela de login da Microsoft dentro da interface do próprio webmail. A vítima, acreditando estar autenticando a sessão novamente, digita a senha, que é então capturada pelo atacante.
Esse ataque é possível graças a uma combinação de fatores: o conjunto de elementos HTML permitidos pelo Outlook, a forma como o próprio aplicativo manipula o DOM via JavaScript interno e uma técnica avançada de exploração de media queries em CSS. Com isso, o invasor consegue assumir controle fino sobre as regras de estilo e “montar” uma página de phishing inteiramente dentro da área de leitura do e-mail.
Para tornar a fraude ainda mais convincente, o ataque disfarça um elemento select, normalmente usado para criar menus suspensos, como se fosse um campo de senha. No Firefox, um comportamento específico do navegador permite que as mudanças na seleção desse elemento sejam capturadas em tempo real, mesmo quando ele é deslocado para fora da área visível da página. Dessa forma, cada caractere escolhido pela vítima pode ser registrado sem que ela perceba.
Vazamento de tokens em Yahoo Mail e AOL Mail
Outra técnica descrita na pesquisa afeta diretamente o Yahoo Mail e o AOL Mail. Nesses serviços, há uma janela de tempo logo após o usuário colar conteúdo HTML em um rascunho de e-mail em que as regras CSS ainda são aplicadas de forma mais permissiva, antes que o sistema de sanitização faça a limpeza completa.
Na prova de conceito, Heyes demonstrou como esse curto intervalo pode ser explorado para revelar trechos de um token de autenticação enviado por serviços que oferecem login por e-mail, como ocorre com algumas plataformas de publicação. O CSS controlado pelo atacante consegue “filtrar” partes do token presentes na mensagem. A partir desses fragmentos, um servidor sob controle do invasor seria capaz de reconstruir o token completo e, assim, acessar a conta da vítima sem precisar da senha.
Esse tipo de ataque mostra que o problema não se limita ao roubo de credenciais digitadas pelo usuário. Muitas aplicações modernas usam links temporários, magic links e tokens de login enviados por e-mail como forma de autenticação simplificada. Se o conteúdo desses códigos puder ser inferido ou parcialmente extraído por meio de CSS, a promessa de conveniência se transforma em um sério risco de segurança.
Exfiltração de dados baseada em cliques para driblar CSP
Para serviços que adotam políticas de Content Security Policy (CSP) mais rígidas, impedindo o carregamento direto de recursos externos, os pesquisadores apresentaram uma técnica de exfiltração baseada em interação do usuário. Em vez de enviar o token ou dado sensível diretamente via requisições de rede, o CSS é usado para “descobrir” quais caracteres específicos aparecem na mensagem.
O mecanismo funciona assim: o atacante injeta uma série de links, cada um associado a uma hipótese de caractere ou sequência. O CSS, controlado por condições, esconde os links que não correspondem ao conteúdo real do token e deixa visível apenas o link que codifica a informação correta. Quando a vítima clica nesse link aparentemente inofensivo, sem saber, ela envia o fragmento de dados ao servidor do atacante por meio da URL acessada.
Esse modelo de ataque explora um ponto fraco difícil de mitigar apenas com CSP: o fato de que, no fim, a ação de clique do usuário é interpretada como legítima pelo navegador, mesmo que tenha sido cuidadosamente orquestrada por regras de estilo maliciosas. Isso reforça a necessidade de restringir não só scripts, mas também o poder expressivo do CSS em ambientes sensíveis.
CSS, e-mail e inteligência artificial: uma combinação perigosa
Um dos capítulos mais inquietantes da pesquisa trata da interação entre webmail e ferramentas de IA conectadas à caixa de entrada. Em um cenário envolvendo o Claude Cowork, da Anthropic, integrado ao Gmail, Heyes demonstrou uma técnica de prompt injection indireta: o conteúdo do e-mail, estilizado e manipulado por CSS, induzia o assistente a executar ações não previstas pelo usuário.
Na prova de conceito, o assistente era levado a localizar um token de autenticação do Slack presente em um e-mail e, em seguida, inseri-lo automaticamente em um rascunho HTML. Uma falha no tratamento da função CSS image-set() no Gmail fazia com que, ao visualizar esse rascunho, o token fosse carregado de forma que pudesse, em tese, ser vazado para um servidor externo controlado pelo atacante.
Isso evidencia um novo vetor de risco: a IA passa a atuar como um “conector” entre dados sensíveis presentes na caixa de entrada e instruções ocultas embutidas em HTML e CSS. Mesmo sem JavaScript explícito, a cadeia de eventos criada pelo assistente abre uma superfície de ataque que muitas empresas ainda não consideram ao avaliar a segurança de integrações com e-mail.
Manipulação da visão humana e da visão da IA
Outro experimento teve como alvo o navegador com IA Atlas, da OpenAI. Usando pseudoelementos CSS e ajustes de opacidade, Heyes montou uma página onde o usuário via apenas um texto aparentemente inocente, enquanto, na estrutura real do documento, existia um conjunto de instruções escondidas para o modelo de IA.
Quando o usuário pedia ao Atlas para traduzir o conteúdo exibido, o modelo não operava apenas sobre o que era visível ao humano, mas sobre todo o texto presente no DOM – incluindo as instruções ocultas. Isso fazia com que a IA executasse ações adicionais, como abrir abas, navegar para URLs específicas e incluir informações sobre a vítima em partes dos endereços acessados.
A OpenAI informou que o Atlas será descontinuado em 9 de agosto de 2026, mas o experimento deixa uma lição importante: qualquer sistema de navegação ou leitura de páginas controlado por IA precisa considerar que o que a IA “enxerga” pode ser muito diferente do que o usuário vê na tela. CSS, transparência, sobreposição de elementos e conteúdo off-screen podem ser usados para criar mensagens secretas destinadas exclusivamente ao modelo.
Fastmail: hotwiring de CSS e rastreamento de leitura
O estudo também descreve ataques de CSS hotwiring contra o Fastmail. Nessa abordagem, o estilo é usado para redirecionar cliques do usuário a ações diferentes das esperadas. Por exemplo, um botão que parece apenas expandir um e-mail pode, na prática, acionar outra função na interface, como arquivar, encaminhar ou até acionar uma requisição indesejada.
Além do desvio de cliques, Heyes demonstrou uma técnica para contornar o proxy de imagens do Fastmail e identificar quando um e-mail foi aberto. Normalmente, provedores utilizam proxies de imagem para impedir que remetentes maliciosos rastreiem a abertura da mensagem, mascarando o IP e outros detalhes do usuário. Porém, com CSS cuidadosamente elaborado, é possível abusar de como o serviço manipula imagens e assim obter sinais confiáveis de visualização.
Esse tipo de técnica é especialmente preocupante em campanhas de phishing e espionagem direcionada, nas quais saber o momento exato em que a vítima lê a mensagem pode orientar os próximos passos do ataque.
Proton Mail e exposição de endereço IP
Em outro teste, o pesquisador explorou um vetor contra o Proton Mail que permitia expor o endereço IP do destinatário, algo que o serviço historicamente busca evitar com mecanismos de privacidade mais rígidos. A abordagem envolvia contornar camadas de proteção usando recursos de CSS, de forma que o acesso a um recurso controlado pelo atacante pudesse ser correlacionado ao ato de leitura da mensagem.
Durante uma nova rodada de validação, Heyes constatou que esse bypass havia deixado de funcionar, indicando que o Proton Mail implementou ajustes de segurança. O Fastmail, por sua vez, também corrigiu duas falhas relacionadas à mutação de CSS. Já algumas técnicas envolvendo Outlook e Gmail continuavam parcialmente viáveis na data de publicação do estudo, o que demonstra a complexidade de corrigir por completo esse tipo de problema.
Por que o CSS virou vetor de ataque?
Historicamente, a maior parte das defesas em aplicações web e webmail foi construída em torno da contenção de JavaScript, iframes e formulários. CSS, por muito tempo, foi considerado “apenas” uma linguagem de apresentação. Porém, ao longo dos anos, o padrão passou a incorporar recursos cada vez mais poderosos, como media queries complexas, pseudo-elementos, funções avançadas para imagens e capacidade de reagir a estados de interação do usuário.
Quando esse poder é aplicado dentro de um ambiente sensível – como a interface de um webmail que já contém scripts legítimos, componentes dinâmicos e integrações com outros serviços – o CSS deixa de ser puramente estético e passa a influenciar o fluxo de interação do usuário e, indiretamente, o comportamento de scripts e ferramentas externas, incluindo IAs.
Além disso, o modelo de sanitização de muitos provedores foi desenhado para remover scripts e atributos perigosos, mas não necessariamente para limitar seletivamente regras de estilo avançadas. O resultado é que, mesmo com JavaScript completamente bloqueado nas mensagens, o atacante ainda consegue atingir objetivos que antes pareciam exigir código executável.
Recomendações para provedores de webmail
Como medidas de mitigação, a PortSwigger sugere que provedores de webmail adotem uma postura muito mais restritiva em relação a HTML e CSS em mensagens. Entre as recomendações estão:
– Isolar e-mails em HTML em iframes com sandbox, reduzindo a possibilidade de interação direta com a interface principal do serviço.
– Reforçar a validação de CSS com listas de caracteres e propriedades explicitamente permitidas, em vez de simplesmente tentar “bloquear o que é perigoso”.
– Proibir ou limitar seletivamente seletores, pseudo-elementos, funções e recursos que possibilitem inferência de conteúdo, redirecionamento de cliques ou manipulação abusiva de layout.
– Restringir atributos personalizados e estruturas que possam servir como canal de comunicação encoberto entre o CSS da mensagem e scripts da aplicação.
– Evitar que mensagens possam controlar diretamente o carregamento de imagens e recursos externos, especialmente se esses recursos puderem ser usados para rastreamento ou vazamento de dados.
Essas ações implicam, inevitavelmente, em reduzir um pouco a liberdade estética do HTML nos e-mails, mas a pesquisa deixa claro que o custo de manter o status quo é alto demais do ponto de vista de segurança.
O que empresas e usuários podem fazer agora
Enquanto os provedores trabalham em correções estruturais, organizações e usuários finais também podem adotar práticas para reduzir a exposição:
– Preferir, sempre que possível, a visualização de e-mails apenas em modo texto para mensagens de remetentes desconhecidos ou inesperados.
– Desconfiar de qualquer tela de login exibida dentro do próprio e-mail ou em overlays suspeitos, mesmo que usem logotipos oficiais.
– Evitar clicar em links que apareçam “do nada” dentro de uma conversa ou que surjam em áreas estranhas da interface.
– Desativar, quando possível, pré-visualizações automáticas muito ricas em HTML em contas mais sensíveis.
– Em ambientes corporativos, segmentar o uso de integrações de IA com e-mail, restringindo o acesso a caixas com dados mais críticos.
Administração de TI pode ainda considerar políticas de segurança adicionais, como filtragem de conteúdo em gateways de e-mail, bloqueio de mensagens com HTML excessivamente complexo e auditoria de uso de extensões de navegador e assistentes que interagem com o webmail.
O impacto na segurança de IA corporativa
A conexão entre e-mail e IA tende a se intensificar: assistentes que resumem mensagens, automatizam respostas ou extraem dados para CRMs já são uma realidade em muitas empresas. A pesquisa de Heyes mostra que esses agentes podem ser induzidos a agir como “ponte” entre dados que deveriam ficar confinados na caixa de entrada e sistemas externos.
Para equipes de segurança, isso significa que o modelo de ameaça precisa ser atualizado. Não se trata mais apenas de proteger o usuário humano contra phishing visual, mas também de proteger o agente de IA contra conteúdo malicioso que apenas ele “lê” ou interpreta. Políticas claras sobre em quais caixas e domínios a IA pode atuar, que tipos de dados ela pode copiar ou reenviar e como logs são monitorados tornam-se parte essencial da governança de segurança.
Um novo capítulo na segurança de e-mail
O trabalho apresentado na Black Hat USA 2026 reforça uma tendência já observada em outros campos: linguagens e recursos que nasceram com objetivo puramente visual ou de conveniência, como CSS, podem se tornar componentes centrais em cadeias de ataque sofisticadas. Em um cenário em que webmail, autenticação por token e IA integrada se cruzam, qualquer brecha de isolamento entre esses elementos abre espaço para abusos criativos.
Para o usuário final, a principal mensagem é de cautela redobrada com e-mails em HTML, mesmo quando exibidos em plataformas tradicionais e conhecidas. Para provedores, fica a urgência de rever o modelo de confiança em torno do CSS e de integrar a segurança de IA às estratégias de proteção de e-mail. O que antes era “só estilo” hoje pode ser a porta de entrada para comprometer contas, roubar tokens e manipular assistentes inteligentes sem que a vítima perceba.