En Black Hat USA 2026, el investigador de PortSwigger Gareth Heyes presentó una charla titulada “CSS: the bomb inside your inbox”, y el hallazgo detrás del título resulta genuinamente incómodo para cualquiera que crea que la autenticación de correo equivale a seguridad de correo. Heyes demostró que el CSS y el HTML por sí solos, sin JavaScript, sin archivos adjuntos y sin ningún enlace malicioso, bastan para construir un keylogger funcional dentro de los principales clientes de webmail, incluidos Gmail, Outlook, Yahoo Mail, AOL Mail, Fastmail y Proton Mail. Las cadenas de ataque que demostró pueden capturar contraseñas, secuestrar elementos de interfaz confiables, filtrar tokens de inicio de sesión y, en un caso, manipular una herramienta de IA que leía el correo en nombre de la víctima. Nada de esto requiere que el remitente suplante identidad alguna. Solo requiere que el cliente de webmail del destinatario renderice el cuerpo del mensaje de la forma en que normalmente lo haría.
Cómo un menú desplegable se convierte en un falso campo de contraseña
La técnica central se basa en peculiaridades de cómo los navegadores implementan CSS, específicamente el comportamiento de mutación, los selectores de atributos y pseudo-elementos como :before, :after, :has() y :checked. Heyes los usó para disfrazar un menú desplegable HTML ordinario como algo que se ve, píxel por píxel, igual a un campo de contraseña. El detalle que hace que capture pulsaciones de teclas en lugar de solo verse convincente es un detalle de implementación de Firefox: el navegador reinicia su temporizador de selección de texto, de aproximadamente un segundo, cada vez que el elemento desplegable se mueve fuera de pantalla y vuelve. Al provocar repetidamente ese reinicio solo con CSS, el ataque dispara una solicitud de imagen de fondo, la clásica técnica de exfiltración por CSS, una vez por cada pulsación, con la suficiente cercanía al tiempo real como para que el atacante reconstruya lo que escribió la víctima carácter por carácter. Ningún script se ejecuta jamás. El cliente de correo simplemente hace lo que las especificaciones de CSS dicen que debe hacer.
Tres cadenas que realmente funcionaron
La investigación no fue teórica. Heyes construyó y demostró cadenas de ataque funcionales contra plataformas de webmail reales y actuales. Una combinación de Outlook y Firefox suplanta una pantalla de inicio de sesión de Microsoft convincente dentro del mensaje y captura la contraseña mientras el destinatario la escribe. Una condición de carrera al pegar texto (“paste race”) en Yahoo Mail y AOL Mail expone un token de inicio de sesión de correo de Medium, permitiendo que el atacante inicie sesión como la víctima sin tocar jamás una contraseña. Una cadena de Gmail que involucra Cowork va todavía más lejos, usando inyección de prompts para manipular una herramienta de IA que lee el correo del destinatario y logrando que filtre un token de Slack tras una pequeña interacción del usuario. Esa última cadena merece atención: a medida que los asistentes de IA se integran en cómo las personas procesan su bandeja de entrada, la propia bandeja se convierte en una superficie de inyección para esos asistentes, no solo para el humano que la lee.
Los parches son desiguales, y parte de esto sigue funcionando
La respuesta de los proveedores ha sido mixta. Fastmail corrigió dos de los errores de mutación de CSS que Heyes reportó. Un bypass de proxy que afectaba a Proton Mail dejó de funcionar cuando volvió a probarlo, lo que sugiere que también ahí llegó una corrección silenciosa. Pero, hasta la publicación de la investigación el 6 de agosto, el problema de “label-jacking” de Outlook y el bypass de image-set() de Gmail seguían siendo funcionales. Esto no es una única vulnerabilidad con un único parche. Es una clase de comportamiento de renderizado que cada proveedor de webmail implementa de forma ligeramente distinta, lo que significa que cada proveedor lo está corrigiendo, o no, según su propio calendario.
Por qué DMARC no tiene nada que decir sobre esto
DMARC verifica exactamente una cosa: si el dominio en el encabezado From de un mensaje estaba autorizado a enviarlo, según la alineación de SPF y DKIM. No dice nada, y nunca se diseñó para decir nada, sobre lo que hace un cliente de webmail con el HTML y el CSS del cuerpo del mensaje una vez que se acepta la entrega. Un correo con una bomba CSS puede originarse en un dominio con una política DMARC configurada en reject, firmado correctamente con DKIM, alineado correctamente con SPF, y pasar cada una de esas verificaciones sin fricción. El ataque no necesita falsificar quién envió el mensaje. Necesita que el navegador del destinatario interprete un bloque de estilos, un comportamiento de la capa de renderizado que queda completamente fuera de lo que inspecciona cualquier protocolo de autenticación de correo. Es la misma brecha estructural que ha aparecido repetidamente este año en el phishing basado en SVG y otras técnicas de contrabando de contenido: DMARC asegura el sobre, y una parte cada vez mayor de los ataques reales ocurre dentro de un contenido que ese sobre nunca fue diseñado para examinar.
Qué significa esto para tu programa
Sanea el HTML y el CSS entrante en la puerta de enlace, no dependas únicamente del filtrado propio del proveedor de webmail. La investigación de Heyes muestra que el saneamiento del lado del proveedor es inconsistente y a veces va meses por detrás de la divulgación. Una capa que controlas captura lo que una corrección del lado del cliente todavía no ha llegado a publicar.
Trata las solicitudes repetidas de imagen de fondo hacia dominios desconocidos como una señal, no como ruido. El mecanismo de exfiltración detrás de los ataques de bomba CSS depende de una avalancha de pequeñas solicitudes de imagen. Un monitoreo de tráfico saliente que marque este patrón puede detectar un ataque que el filtrado de contenido nunca ve.
Entrena a los usuarios para que una pantalla de inicio de sesión o un campo de contraseña renderizado dentro del cuerpo de un correo nunca es legítimo, sin importar lo convincente que parezca. Las solicitudes reales de autenticación provienen del propio navegador o de una página cargada por separado, nunca desde el interior de un mensaje.
Exige a tus proveedores de webmail y seguridad un calendario concreto de parches, especialmente si tu organización usa Outlook o Gmail, donde los bypasses específicos divulgados por Heyes seguían funcionando hasta la publicación.
Mantén DMARC aplicado en reject de todos modos. Sigue siendo la defensa correcta contra la suplantación directa de dominio, y un correo con bomba CSS generalmente aún necesita un dominio que el atacante controle para enviarlo. Simplemente no es, y nunca pretendió ser, una defensa contra lo que ocurre después de que el correo de ese dominio llega a la bandeja de entrada.
La conclusión
La autenticación de correo y la seguridad del renderizado resuelven problemas distintos, y 2026 sigue aportando recordatorios frescos de cuán distintos son. Un mensaje puede estar completamente autenticado, perfectamente alineado, y aun así detonar en el momento en que un navegador hace su trabajo ordinario de interpretar CSS. La investigación de Heyes no significa que DMARC haya fallado en nada. Significa que la exposición restante de la industria se ha desplazado hacia la capa que DMARC nunca fue diseñado para cubrir, y cerrar esa brecha ahora depende del saneamiento de contenido a nivel de puerta de enlace y de la concienciación del usuario, junto a una autenticación sólida, no de la autenticación por sí sola.
Excello Mail te da visibilidad continua sobre el cumplimiento de tu DMARC y sobre cada fuente autorizada a enviar bajo tu dominio, para que la capa de autenticación se mantenga bien asegurada mientras tu equipo se enfoca en los riesgos a nivel de contenido que DMARC nunca fue diseñado para detectar. Regístrate gratis en Excello Mail y descubre exactamente quién está enviando correos en tu nombre, todo el tiempo.