Una nueva línea de investigación alerta sobre ataques CSS en webmail: técnicas que aprovechan cómo los clientes de correo renderizan contenido HTML y hojas de estilo dentro de la interfaz. La idea central es que partes del mensaje, que deberían permanecer aisladas, pueden acabar afectando controles o acciones que el sistema considera “de confianza”.
Según el trabajo presentado por el investigador de PortSwigger Gareth Heyes, las cadenas de ataque demostradas abarcan varios servicios populares y llegan a escenarios sensibles: captura de contraseñas, robo de tokens de inicio de sesión, toma de cuentas de terceros, exfiltración mediante interacciones del usuario y manipulación de herramientas basadas en IA que leen el correo. A continuación, repasamos los hallazgos y, sobre todo, qué medidas defensivas se proponen.
Cómo un email puede “salirse” del mensaje
El estudio describe dos rutas generales para lograr el escape. La primera consiste en abusar de HTML y CSS que el webmail ya permite. La segunda busca crear una discrepancia entre lo que un sanitizador (filtro de contenido) aprueba y lo que finalmente crea el navegador o la aplicación.
En ambos casos, el contenido no confiable del email puede cruzar el límite que separa el mensaje de la interfaz que el usuario usa para gestionar su cuenta. Si esa frontera se rompe, el atacante puede influir en elementos, solicitudes de red o flujos de interacción que normalmente estarían protegidos por controles del producto.
Ejemplos de ataques CSS en webmail por plataforma
Outlook y Firefox: suplantación y captura de credenciales
Una de las cadenas descritas combina un ajuste a nivel de interfaz con un escenario de navegador. El flujo mostrado engaña a la víctima con una pantalla de inicio de sesión que imita a un proveedor, permitiendo capturar la contraseña que el usuario escribe.
El reporte puntualiza que el documento presenta investigación con pruebas de concepto y no confirma explotación maliciosa real. Aun así, el riesgo operativo es claro: cuando el contenido del correo puede intervenir en controles de confianza, el atacante no necesita depender de una simple estafa visual.
Yahoo Mail y AOL Mail: carreras de pegado y tokens
En Firefox, el estudio recoge una vía basada en el pegado de HTML. Durante un breve momento, el contenido podría conservar CSS activo antes de ser sanitizado. El ejemplo de demostración usa un flujo de inicio de sesión para Medium: el atacante hace que la víctima copie CSS al portapapeles y luego lo pegue en un borrador de Yahoo o AOL.
Con ese paso, se revelan suficientes detalles de un token de acceso, de forma que el atacante puede reconstruirlo en su servidor y posteriormente iniciar sesión como la víctima.
Gmail: exfiltración de tokens vinculados a plataformas de trabajo
El trabajo también incluye una cadena asociada a Gmail que busca extraer un token de Slack. El mecanismo se basa en inyección mediante prompts y en la interacción del usuario para encadenar el resultado.
En otras palabras, no se trata únicamente de robar datos “por petición externa”: el atacante pretende que el entorno de correo desencadene eventos que acaben revelando información autenticada en un contexto que el usuario cree legítimo.
Exfiltración con clics cuando hay restricciones de recursos externos
El documento introduce un método de exfiltración apoyado en clics, útil en escenarios donde una Content Security Policy (CSP) bloquea la carga de recursos externos. Si el email contiene una inyección de estilos y un token numérico renderizado como texto, CSS puede inferir qué dígitos aparecen y con qué frecuencia.
La idea es que el CSS puede ocultar enlaces que no coinciden, y dejar visible el enlace correcto. Después, el usuario hace clic y ese evento permite que el sistema del atacante reciba los dígitos y su frecuencia. Así, aun con restricciones de red, el flujo de interacción puede convertirse en canal de salida.
Interacción con funciones de confianza y acciones de terceros
Una parte especialmente relevante del estudio es la combinación de piezas que, por separado, podrían no ser tan peligrosas. El reporte detalla cómo elementos permitidos en Outlook pueden desencadenar controles fuera del mensaje, y cómo una lógica de JavaScript de la aplicación puede transformar atributos personalizados sanitizados en nodos del DOM adicionales que ya incluyen CSS fuera de la lista permitida.
Luego aparece un truco relacionado con el análisis de media queries que termina entregando al atacante CSS arbitrario. La cadena final oculta el objetivo: disfraza un campo tipo “select” como si fuese un campo de contraseña. En Firefox, además, el temporizador de selección de opciones puede reiniciarse cuando el elemento se desplaza fuera de la vista, lo que hace que la captura ocurra en tiempo real.
Cuando la interfaz lee el correo por una vía conectada
El estudio también mira más allá del navegador y entra en el terreno de correo “conectado” a asistentes. En un escenario con Gmail, se menciona que un mecanismo de reserva relacionado con image-set() podría provocar una solicitud externa incluso tras la sanitización.
La demostración enlaza este punto con una inyección de prompt en un correo procesado por un conector a una herramienta de trabajo que colabora con un servicio de IA. Tras disparar un correo de confirmación de un token de Slack, el usuario pide que la herramienta procese los correos. Las instrucciones inyectadas hacen que el sistema recupere el token y lo inserte en un borrador HTML; al ver ese borrador, el dato queda expuesto.
Fastmail y proxies: correcciones y vectores adicionales
En cuanto a resultados operativos y estado de mitigaciones, el investigador señala que en Fastmail se corrigieron dos problemas ligados a “mutaciones” de CSS. También indica que un bypass tipo proxy en Proton Mail dejó de funcionar al retestearlo.
En Fastmail se describen otras piezas: lo que el documento llama “CSS hotwiring”, capaz de redirigir clics hacia acciones de interfaz no previstas, incluso con pasos múltiples. También se menciona un bypass de proxy de imágenes que depende de un dominio permitido para revelar cuándo se visualiza un email.
Proton Mail y exposición de IP
Otra demostración independiente involucra Proton Mail y muestra un vector que podría exponer la dirección IP del destinatario. El reporte recuerda que la documentación actual de protección contra rastreadores busca ocultar la IP personal y el momento exacto en que se abre un mensaje.
Este punto es importante porque, aunque el foco mediático suele estar en contraseñas y tokens, la privacidad también se ve comprometida si el servicio permite correlaciones que identifiquen al usuario o su actividad.
Recomendaciones defensivas del estudio
El trabajo no solo describe cadenas de ataque: propone un enfoque defensivo en capas. La recomendación principal empieza con el aislamiento estricto del HTML del email dentro de iframes con sandbox. Desde allí, el documento sugiere limitar con precisión CSS y otros componentes que podrían convertirse en “ganchos” de ataque.
Entre las medidas mencionadas están: aplicar listas de caracteres para validar CSS, revisar si existen “gadgets” de CSS antes de permitir atributos personalizados, bloquear menús select y selectores peligrosos, y prevenir solicitudes de imágenes controladas por atacantes y dominios permitidos.
Además, el estudio subraya el riesgo de la discrepancia entre sanitización y renderizado: si el sanitizador no garantiza que el navegador o la aplicación finalicen creando exactamente lo previsto, aparece una superficie nueva donde el atacante puede maniobrar.
Qué significa para usuarios y equipos
En la práctica, los ataques CSS en webmail muestran que la seguridad del correo no se reduce a “no ejecutar scripts”. El CSS, los atributos personalizados, el modo en que la interfaz traduce interacciones y el procesamiento por conectores o sistemas de IA pueden actuar como puentes para exfiltración y secuestro de sesión.
Si gestionas una organización, revisa políticas de aislamiento para vistas de email, valida cómo se aplica el filtrado de estilos y atributos, y verifica qué eventos del usuario se registran o se usan para llamadas internas. Si eres usuario, mantén la precaución ante correos con acciones urgentes, evita interactuar con borradores o flujos que soliciten copiar/pegar contenido, y activa medidas de protección de cuenta como autenticación multifactor cuando el servicio lo permita.
Estado del riesgo: PoCs disponibles y pruebas de mitigación
El reporte indica que las pruebas de concepto públicas permanecían disponibles al 8 de agosto. También puntualiza el estado de algunos parches: se mencionan correcciones en Fastmail, y en el momento del artículo ciertos bypass aún funcionaban en Outlook label-jacking y en Gmail con el bypass de image-set() según la publicación del 6 de agosto.
Por eso, incluso si algunos vectores se corrigieron, la lección general se mantiene: sin aislamiento robusto y validación estricta del contenido, pequeñas diferencias entre lo que se permite y lo que se renderiza pueden dar lugar a nuevas cadenas.
Conclusión
Los ataques CSS en webmail convierten el correo en un entorno potencialmente manipulable, donde CSS y HTML pueden afectar controles confiables, filtrar credenciales y tokens, y hasta influir en sistemas que procesan mensajes conectados a terceros o a IA. El estudio de PortSwigger presentado en Black Hat USA 2026 refuerza una idea: para defender webmail de forma efectiva, necesitas aislamiento real, validación estricta y coherencia entre lo que se sanitiza y lo que termina apareciendo en la interfaz.
Si tu objetivo es reducir riesgo, empieza por el aislamiento con sandbox, restringe con rigor CSS y atributos, bloquea menús y selectores problemáticos, y corta cualquier solicitud de recursos o dominios que no sean estrictamente necesarios. Con ese enfoque, el correo deja de ser una “zona gris” y vuelve a estar acotado a lo que el sistema realmente debe mostrar.
Fuente: https://thehackernews.com/2026/08/new-css-attacks-can-break-webmail.html
