Noticias
Ataque CSS en el correo: un mensaje puede robarte la contraseña de Outlook sin una línea de JavaScript
Un investigador demostró que un correo puede robarte la contraseña sin usar una sola línea de JavaScript. El ataque CSS en el correo que Gareth Heyes presentó en Black Hat USA 2026 no necesita adjuntos ni archivos que descargar: alcanza con el HTML y las hojas de estilo que tu webmail ya considera seguras. En la demostración más lograda —hecha sobre Outlook en el navegador y con Firefox— el mensaje se apodera de toda la pantalla, dibuja encima una pantalla de inicio de sesión de Microsoft y captura, tecla por tecla, lo que la víctima escribe.
Lo que vas a encontrar acá
- Qué es y por qué rompe todos los supuestos
- El golpe a Outlook: del clic robado al login clonado
- Gmail, Yahoo, AOL, Fastmail y Proton: qué le pasó a cada uno
- Cuando el que lee tu correo es una inteligencia artificial
- Qué respondieron los proveedores (y qué no)
- Lo que el paper le pide a los proveedores, no a vos
- ¿Y esto qué significa para vos?
- Preguntas frecuentes
Qué es el ataque CSS en el correo y por qué rompe todos los supuestos
Durante décadas el webmail resolvió el mismo problema: mostrarte HTML que escribió un desconocido sin que te haga daño. La herramienta para eso es el sanitizador, que deja pasar solo lo que considera inofensivo. Y el CSS —colores, tamaños, posiciones— siempre estuvo de ese lado. Es decoración. No ejecuta nada.
Eso es lo que la investigación viene a discutir. Heyes lo plantea sin vueltas al abrir su trabajo, publicado por PortSwigger Research:
Es bastante común que los clientes de webmail rendericen CSS no confiable dentro de una interfaz confiable. Intentan hacerlo seguro mediante sanitización de CSS. En este paper voy a mostrarte cómo romper los límites de confianza, exfiltrar tokens, comprometer sitios de terceros e incluso robar contraseñas.
Gareth Heyes, investigador de PortSwigger — ver la investigación
El problema de fondo tiene un nombre feo y una idea simple: discrepancia. El sanitizador cree que aprobó una cosa y el navegador termina construyendo otra. Alcanza con eso para que el contenido de un mensaje se escape de su cajita y empiece a tocar la interfaz que lo muestra.
| Dato | Detalle |
|---|---|
| Investigación | CSS: the bomb inside your inbox |
| Autor | Gareth Heyes, PortSwigger Research |
| Charla | Black Hat USA 2026, jueves 6 de agosto, 14:35, sala South Seas C&D |
| Paper publicado | 6 de agosto de 2026, 22:00 UTC — veinticinco minutos después de la charla |
| Ingredientes | CSS y HTML. Cero JavaScript, cero adjuntos, cero archivos que descargar: el correo más limpio que vas a recibir en tu vida |
| Servicios analizados | Outlook, Gmail, Yahoo Mail, AOL Mail, Fastmail y Proton Mail |
| Código de prueba | Público, en un repositorio de GitHub |
| Explotación real | El paper no reporta ningún uso malicioso: son pruebas de concepto, no una campaña activa |
El golpe a Outlook: del clic robado al login clonado
La cadena contra Outlook es la que mejor muestra cómo se apilan las piezas, y arranca con un elemento que casi nadie mira: la etiqueta <label>. Sirve para asociar un texto con un campo de formulario y, según explica el propio paper, hereda el clic de ese campo. Si un sanitizador la deja pasar sin filtrar su atributo for, un correo puede accionar controles que están fuera del mensaje.
Heyes encontró exactamente eso, y el señuelo es tan viejo como internet: dos etiquetas que dicen «hacé clic acá primero» y «hacé clic acá para fijar este mensaje». Si la víctima muerde, la primera abre la cinta de opciones de Outlook y la segunda ancla el mensaje del atacante en su buzón. El paper dice haber encontrado el mismo agujero en al menos tres clientes de webmail, y sobre Outlook agrega una frase que conviene leer despacio, porque está en presente:
Esto todavía funciona hoy porque Microsoft no lo arregló.
Gareth Heyes, sobre el abuso de etiquetas en Outlook — ver la investigación
La segunda pieza es lo que el autor bautizó «CSS gadget»: Outlook permite atributos de datos personalizados, y una de sus propias librerías los usa para agregar elementos al documento con propiedades CSS que están fuera de la lista blanca del sanitizador. Una de ellas es position:fixed, que ubica un elemento en cualquier lugar de la pantalla. Traducido: el mensaje sale de su ventana y se planta sobre la aplicación.
La tercera es el quiebre del sanitizador. Tras una tanda larga de pruebas que el paper reproduce entrada por entrada, Heyes dio con una consulta de medios mal interpretada que, combinada con un comentario que abre comillas, le entregaba control total del CSS de la página. Con eso montó un registrador de teclas sin JavaScript: un menú desplegable disfrazado de campo de contraseña, donde cada letra elegida dispara una petición a un servidor externo.
Ese registrador funciona, pero tiene un problema de credibilidad: cuando la tecla siguiente no sigue el orden alfabético, el navegador se toma casi un segundo antes de aceptarla, y el autor admite que así «no era probable que engañara a alguien». Lo que lo vuelve creíble es un rasgo de Firefox: mover el elemento fuera de la pantalla reinicia ese temporizador, y devolviéndolo en fracciones de milisegundo la captura pasa a ser instantánea. Con esa pieza, el paper cierra con una demostración en la que —textual— el correo «toma la pantalla completa, imita la pantalla de inicio de sesión de Outlook y roba la contraseña en Firefox«.
Un matiz que cambia el alcance: robar contraseñas no depende de Firefox, pero hacerlo de forma convincente sí. Para Chrome, Heyes describe una variante con atributos HTML nuevos y aclara que hoy «es poco probable que un sanitizador de HTML los permita». Es una idea a futuro, no algo que esté funcionando.
Gmail, Yahoo, AOL, Fastmail y Proton: qué le pasó a cada uno
Outlook se lleva el titular, pero el trabajo recorre seis servicios y a cada uno le encontró algo distinto. Nada de esto explota una falla del correo como protocolo, sino de cómo cada aplicación decide mostrarte un mensaje ajeno.
| Servicio | Qué se demostró | Estado, según el autor |
|---|---|---|
| Outlook (web) | Control de la interfaz con etiquetas, salida de la ventana del mensaje vía «CSS gadget» y registrador de teclas que clona el login de Microsoft | El abuso de etiquetas sigue activo: «Microsoft no lo arregló». Sobre la cadena completa, el paper no informa corrección |
| Gmail | Evasión del proxy de imágenes con image-set(), para saber cuándo abriste el correo | «Gmail sigue siendo vulnerable a esto, a pesar de numerosos mensajes para convencerlos de que es un problema» |
| Yahoo Mail y AOL Mail | En Firefox, condición de carrera al pegar en un borrador: el CSS queda activo un instante, suficiente para exfiltrar un token hexadecimal de 12 caracteres | «Yahoo Mail y AOL Mail tienen la misma condición de carrera» |
| Fastmail | Dos mutaciones de CSS; evasión del proxy vía un dominio permitido; y «CSS hotwiring», que secuestra cualquier clic de la página | Las dos mutaciones, corregidas (US$ 1.000 de recompensa cada una). Sobre la evasión del proxy, sin corrección informada |
| Proton Mail | Evasión del proxy que permitía incrustar la IP del destinatario dentro del mensaje | Proton respondió que no era un fallo válido; meses después «parece que lo arreglaron en silencio» |
El caso de Yahoo y AOL merece una aclaración, porque no basta con recibir el correo: hacen falta tres cosas. El atacante primero dispara un inicio de sesión por correo contra la víctima —en la demostración, el de Medium, que manda un token—; después ella tiene que copiar contenido del atacante y pegarlo en un borrador; y todo eso, en Firefox.
Cuando el que lee tu correo es una inteligencia artificial
La parte más nueva del trabajo no apunta a un humano, sino a los asistentes que hoy leen la bandeja de entrada por nosotros. Heyes trabajó con su colega Pete Hendy para encadenar la evasión del proxy de Gmail con una inyección indirecta de instrucciones contra Cowork, una herramienta que —según detalla el paper— tiene un conector de Gmail que le permite leer el correo y redactar borradores en nombre del usuario. The Hacker News agrega el apellido: es Cowork, de Anthropic.
El montaje es prolijo: un correo escrito como si fuera el pedido de un compañero de trabajo, con la excusa de completar un desafío de seguridad. Cuando el usuario le pide al asistente que procese los correos, este lee el pedido, busca un token de acceso a Slack que estaba en otro mensaje y lo pega dentro de un borrador. Al abrir ese borrador, el estilo dispara la petición y el token se va.
La segunda demostración apuntó a Atlas, el navegador con inteligencia artificial de OpenAI, dentro de Fastmail. Con pseudoelementos y opacidad, el texto que ve la persona y el que lee el modelo son distintos: uno es inofensivo y el otro lleva instrucciones. Cuando el usuario pide traducir lo que ve, el modelo abre pestañas y filtra su nombre en el fragmento de la URL. Detalle con fecha de vencimiento incorporada: OpenAI anunció en su centro de ayuda que discontinúa Atlas, que está previsto que deje de funcionar el 9 de agosto de 2026 y que sus capacidades pasan a ChatGPT y Codex.
Qué respondieron los proveedores (y qué no)
Acá conviene ser preciso, porque es donde más fácil se exagera. Lo que el paper documenta son las respuestas que recibió el investigador durante el proceso de reporte, no comunicados públicos posteriores a la charla.
Fastmail sale bien parado: corrigió las dos mutaciones, pagó recompensa por cada una y el autor describe la colaboración como un placer. Proton, en cambio, primero rechazó el reporte —»dijeron que no era un fallo válido»— y Heyes lo contrasta con la documentación de la propia empresa, que en la versión que él cita prometía que los remitentes no pueden usar imágenes remotas para determinar de forma confiable quién, cuándo ni dónde se abre un correo. Esa redacción ya no está: la página viva hoy dice que la protección oculta «tu dirección IP personal, la información del dispositivo y el momento exacto en que abriste el correo». Meses más tarde, al reintentar el ataque, ya no funcionaba.
Con Gmail el desenlace fue otro: quien evaluó el reporte creyó que el ataque requería interacción del usuario porque Heyes estaba editando el correo con las herramientas de desarrollo, cuando las usaba solo para armar el mensaje. Terminó abandonando el intento de convencerlos.
Sobre Microsoft, lo único documentado es la frase del paper: el abuso de etiquetas sigue funcionando. Ni PortSwigger ni la cobertura del 8 de agosto registran un identificador CVE, un aviso de seguridad ni declaraciones de Microsoft o de Google. Y hay una segunda capa de silencio: al cierre de esta nota la investigación tenía dos medios en inglés —Dark Reading, con una entrevista previa a la charla, y The Hacker News—, cero cobertura en español y un hilo en Hacker News con dos puntos y un único comentario, que es toda la conversación pública que generó el tema:
La cantidad de funcionalidad que hay en lo que consideramos «estilo» es increíble.
@JSR_FDED en Hacker News, 8 de agosto — ver el hilo
Lo que el paper le pide a los proveedores (no a vos)
Conviene dejarlo claro: la sección de defensas del trabajo está dirigida a quienes desarrollan clientes de correo, no a quien lo usa. Heyes pide aislar el mensaje en marcos restringidos, bloquear los menús desplegables en el sanitizador, prohibir selectores como :has y :checked, e impedir que un mensaje pueda pedir imágenes externas. Cierra con un dardo corto sobre el proxy de imágenes: «Outlook ni siquiera tenía uno».
¿Y esto qué significa para vos?
Primero, la parte tranquilizadora, que es real: no existe acá un ataque que se dispare solo por abrir el correo y te vacíe la cuenta. Todas las cadenas serias necesitan una acción tuya —escribir la contraseña en la pantalla falsa, hacer un clic, pegar algo en un borrador, pedirle al asistente que procese la bandeja— y no hay ninguna campaña activa documentada.
Ahora la parte incómoda, y empieza por una advertencia del propio investigador: acá no hay una casilla que puedas destildar. Dark Reading lo resume así — la responsabilidad recae en las empresas, porque un usuario no puede hacer gran cosa a menos que sepa de HTML y CSS:
No podés apagar el CSS. Pero desde la perspectiva del webmail, sí podés aislar los mensajes usando una tecnología que impida que interfieran con el resto de la página. Y el webmail también puede producir una sanitización más efectiva del CSS.
Gareth Heyes — vía Dark Reading
Así que seamos honestos: lo que sigue no son defensas contra el ataque —esas las pone el proveedor de tu correo— sino formas de no ser vos quien completa la cadena. Y la primera contradice lo que nos enseñaron: mirar la barra de direcciones acá no sirve. La barra dice la verdad, estás en tu webmail de siempre; lo que miente es lo que hay dibujado abajo. El único reflejo confiable es este: ninguna pantalla de inicio de sesión que aparezca mientras leés un mensaje merece tu contraseña. Si tu correo te pide reautenticarte, cerrá la pestaña, abrí otra y entrá vos al servicio.
Ojo con una tentación: que tu gestor de contraseñas no te avise nada no significa nada. El ataque corre sobre el dominio real de tu webmail, así que su chequeo de dominio pasa; y como el campo falso es un menú desplegable, tampoco va a ofrecer completarlo. Lo que sí hace un gestor es contener el daño: si cada servicio tiene su clave, la que te roben no abre nada más.
Dos hábitos para cerrar. El primero sale del paper: no pegues dentro de un borrador contenido que copiaste de una página cualquiera. El segundo es lectura nuestra, no del trabajo de Heyes: si usás un asistente de inteligencia artificial conectado al correo, asumí que cada mensaje que ese asistente lee puede llevar instrucciones dirigidas a él — otro capítulo del mismo expediente que abrimos cuando unos agentes de IA crearon identidades falsas para colar malware. Y una nota al pie para el lector de esta parte del mundo: te estás enterando antes que casi cualquier hispanohablante, porque ningún medio en español cubrió esto. Tampoco te lo va a avisar tu proveedor de correo.
Preguntas frecuentes sobre este ataque por correo
¿Me pueden robar la contraseña con solo abrir el mail?
No. La cadena que roba credenciales necesita que escribas tu contraseña en la pantalla falsa que el mensaje dibuja encima del webmail, y la demostración completa se hizo sobre Outlook en el navegador, con Firefox. Lo que sí puede pasar sin que hagas nada es que el remitente confirme que abriste el correo.
¿Un antivirus me protege de este ataque?
No. El estilo malicioso se procesa dentro de tu webmail, en el navegador, y no hay ningún archivo que analizar. La investigación es clara en que la solución tiene que venir del proveedor de correo. Del lado tuyo, lo único que ayuda es no escribir la contraseña ahí y que esa clave no se repita en otros servicios.
¿Outlook ya está arreglado?
Parcialmente y sin certeza pública. El propio investigador dice que el abuso de etiquetas seguía funcionando cuando publicó el trabajo, el 6 de agosto de 2026, porque Microsoft no lo corrigió. Sobre la cadena completa que captura contraseñas, el paper no aclara si fue solucionada, y Microsoft no publicó nada al respecto.
¿Esto afecta a la aplicación de escritorio o solo al correo en el navegador?
El trabajo se hizo sobre clientes de correo web abiertos en un navegador: Outlook, Gmail, Yahoo, AOL, Fastmail y Proton. No analiza las aplicaciones de escritorio ni las de celular, así que sobre ellas no hay nada que se pueda afirmar a partir de este paper.
¿Y vos qué opinás? Dejalo en los comentarios ⬇️
Que una clave robada no se lleve todas →
