Los ataques CSS en webmail exponen un punto ciego en las defensas de correo electrónico con IA
Google News ha destacado un ataque CSS en webmail detectado en más de un millón de mensajes de phishing desde abril de 2026. La campaña expone un conflicto básico en la seguridad del correo electrónico con IA. Las personas y las máquinas pueden recibir el mismo mensaje, pero leer contenidos radicalmente distintos.
La técnica reportada, denominada text salting, utiliza Cascading Style Sheets para ocultar texto de relleno dentro de un correo electrónico HTML. Ese material oculto cambia la forma en que los sistemas automatizados interpretan el mensaje sin modificar lo que ve el destinatario.
Los investigadores de Barracuda hallaron la técnica en campañas de phishing temáticas de comercios que prometían recompensas, tarjetas regalo, puntos de fidelidad o canjes urgentes. Los atacantes utilizaron texto oculto para diluir el lenguaje sospechoso y hacer que los correos maliciosos pareciesen más seguros ante los filtros automatizados.
No se trata simplemente de otro truco para evadir filtros de spam. La misma brecha de visibilidad puede operar en sentido contrario. Las instrucciones ocultas pueden dirigirse a un asistente de IA que resume correo, redacta respuestas, busca en un buzón o invoca herramientas conectadas.
Esto crea la disyuntiva central de seguridad. Las herramientas de correo con IA se vuelven más útiles a medida que leen más contexto y reciben mayor acceso. Esas mismas capacidades amplían las consecuencias cuando contenido de correo no confiable influye en el modelo.
Las defensas tradicionales asumen que el mensaje mostrado a una persona es, en líneas generales, equivalente al mensaje inspeccionado por el software. CSS rompe esa premisa al crear versiones separadas, una visible para las personas y otra legible por máquinas, dentro de un mismo correo.
La presión inmediata recae sobre Google, Microsoft, los proveedores de seguridad de correo y los desarrolladores que crean asistentes sobre datos de buzones. Deben conciliar el análisis del mensaje sin procesar con el contenido renderizado, preservando al mismo tiempo la accesibilidad y el formato legítimo.
Lo que revela el informe de Google News sobre el text salting
El cambio importante no es que los atacantes hayan descubierto el texto oculto. Es que los métodos de evasión antiguos ahora funcionan contra el criterio basado en IA.
El text salting añade palabras inocuas o sin relación contextual a un mensaje malicioso. El software de seguridad analiza esas palabras, pero CSS impide que el destinatario las vea.
Barracuda informó de la detección de un millón de ataques que utilizaban estas técnicas desde abril de 2026. Los mensajes pertenecían a una campaña temática de comercios basada en ofertas de recompensas y canjes.
Los atacantes utilizaron varias propiedades CSS comunes. clip-path: inset(100%) reducía a cero el área visible de un bloque de texto. Las reglas de altura cero e interlineado cero eliminaban el espacio en blanco sospechoso.
Otras reglas desplazaban el texto más allá del límite de la pantalla. Un gran valor negativo de text-indent lo movía miles de píxeles hacia la izquierda, mientras que overflow: hidden ocultaba una barra de desplazamiento reveladora.
Los atacantes también reducían las fuentes a cero. Ninguna de estas propiedades es maliciosa por naturaleza. Esa ambigüedad hace que una simple lista de bloqueo sea poco fiable, porque las plantillas de correo legítimas pueden utilizar técnicas de estilo relacionadas.
Según los informes, la campaña se apoyaba en sitios web comprometidos o dominios similares. Algunos dominios admitían autenticación estándar de correo, incluido DomainKeys Identified Mail, o DKIM, que verifica que un dominio autorizado haya firmado un mensaje.
DKIM no determina si el contenido es honesto. Valida la gestión e integridad del mensaje a nivel de dominio. Un operador malicioso que controla un dominio autenticado aún puede distribuir phishing.
Esta distinción importa porque los sistemas de IA suelen combinar muchas señales. La autenticación, el lenguaje natural, la reputación del remitente, los enlaces visibles y la estructura del mensaje pueden influir individualmente en una clasificación.
El text salting manipula la señal lingüística. Proporciona a un clasificador un mayor volumen de texto de apariencia benigna, al tiempo que mantiene claro el señuelo de phishing para el destinatario humano.
Un filtro que examine el HTML sin procesar podría encontrarse con párrafos sobre actividad empresarial no relacionada, atención al cliente o transacciones comerciales habituales. El destinatario podría ver únicamente un aviso urgente de recompensa y un botón.
Esto crea una versión semántica de la entrada adversarial. El atacante no está explotando necesariamente un fallo de memoria del software. Está moldeando la evidencia utilizada por un sistema de decisión estadístico.
La IA generativa también reduce el coste de producir relleno variado. Los atacantes pueden crear pasajes benignos distintos para cada mensaje, reduciendo el valor de la coincidencia exacta de texto.
Por tanto, el titular de Google News apunta a un cambio más amplio. El contenido de correo ahora puede diseñarse para dos audiencias, con una historia para el usuario y otra para la máquina.
Por qué los filtros de correo con IA afrontan un problema de renderizado
Un modelo de IA no puede evaluar un correo de forma fiable cuando su entrada no coincide con el mensaje mostrado al destinatario.
Muchos sistemas de seguridad de correo inspeccionan el contenido sin procesar porque contiene evidencia valiosa. Expone URL, atributos HTML, metadatos, secciones codificadas y texto que el renderizado podría ocultar.
Ese enfoque tenía sentido cuando el texto oculto se dirigía principalmente a la puntuación de spam basada en palabras clave. Los defensores podían buscar formatos sospechosos y comparar las palabras visibles con la fuente subyacente.
Los modelos de lenguaje de gran tamaño complican el proceso. Pueden inferir significado a lo largo de pasajes extensos, pero esa capacidad también da mayor influencia al relleno oculto sobre la clasificación.
Un modelo podría ver un mensaje dominado por lenguaje comercial común. Su solicitud visible de phishing podría ocupar solo una pequeña parte de la entrada total legible por máquina.
El ataque no requiere que el modelo siga una orden directa. Puede tener éxito desplazando el tema, tono o intención aparentes lo suficiente como para generar una clasificación benigna.
El análisis renderizado presenta sus propios problemas. Los clientes de correo difieren en su compatibilidad con HTML y CSS. Un mensaje puede mostrarse de forma distinta en Gmail, Outlook, aplicaciones móviles y software especializado de webmail.
Las funciones de accesibilidad también pueden exponer texto que un renderizado visual predeterminado oculta. Los lectores de pantalla, los modos de alto contraste y las vistas simplificadas complican cualquier afirmación sobre una presentación definitiva.
Por ello, las herramientas de seguridad necesitan más que una captura de pantalla. Necesitan una comparación estructurada entre el contenido sin procesar, el diseño calculado, la salida de accesibilidad y los elementos que un usuario típico puede percibir.
La pregunta más útil no es si una propiedad parece sospechosa de forma aislada. Es si el estilo crea una diferencia significativa entre la interpretación de la máquina y la percepción humana.
Un párrafo de tamaño cero que contiene cientos de palabras no relacionadas es una señal más sólida que una sola etiqueta de formato oculta. Los grandes bloques fuera de pantalla merecen un escrutinio similar.
Los defensores también pueden comparar el significado lingüístico de las regiones visibles y ocultas. Un mensaje sobre recompensas de fidelidad no debería contener párrafos ocultos sobre facturas no relacionadas, viajes o atención al cliente.
Sin embargo, los atacantes pueden adaptarse. Pueden generar relleno que se mantenga próximo al tema visible, reduciendo la diferencia semántica mientras diluyen frases maliciosas.
Esto crea una carrera armamentística entre la generación de contenido y la detección consciente de la visibilidad. Un filtro debe comprender no solo lo que dice el mensaje, sino qué partes importan para la persona que lo recibe.
El aprendizaje automático no es inútil en este caso. Sigue siendo valioso para detectar anomalías estructurales, patrones de remitentes, infraestructura de campañas y combinaciones inusuales de reglas de estilo.
El problema es la excesiva confianza arquitectónica. Un modelo de lenguaje no puede compensar una canalización de entrada que mezcla instrucciones confiables, contenido no confiable y material invisible sin límites claros.
Google ha descrito una defensa por capas contra la inyección indirecta de prompts. Su enfoque incluye clasificadores de contenido, entrenamiento adversarial, red teaming y confirmación antes de acciones sensibles.
Estos controles ilustran la dirección que deben tomar las defensas de correo. Ningún veredicto de un único modelo debería decidir si un mensaje es seguro, especialmente cuando CSS cambia lo que reciben distintos observadores.
El contenido oculto puede dirigirse al filtro o al asistente
La misma brecha de visibilidad de CSS permite dos ataques opuestos: ocultar texto benigno a las personas y ocultarles instrucciones maliciosas.
El text salting intenta hacer que un correo malicioso parezca benigno ante un sistema de seguridad. La inyección indirecta de prompts intenta hacer que un asistente de IA obedezca instrucciones que el usuario nunca proporcionó conscientemente.
OWASP define la inyección indirecta de prompts como instrucciones maliciosas integradas en contenido externo que un sistema de IA procesa posteriormente. El correo electrónico es un canal de entrega natural porque cualquiera puede enviar información a muchos buzones.
Un atacante puede ocultar instrucciones con texto blanco, fuentes de tamaño cero, posicionamiento fuera de pantalla, caracteres codificados o estructuras HTML omitidas por el renderizador visual.
La víctima puede pedir a un asistente que resuma mensajes no leídos. Un flujo de trabajo autónomo puede procesar la bandeja de entrada sin ninguna solicitud directa. En ambos casos, el modelo puede encontrar instrucciones redactadas por el atacante.
Un ataque simple podría manipular un resumen. La IA podría inventar una advertencia de seguridad, ocultar un indicador de phishing o describir un mensaje malicioso como aprobado.
Un ataque más grave se vuelve posible cuando el asistente puede buscar otros mensajes, leer documentos conectados, redactar correo saliente o llamar herramientas externas.
El correo malicioso pasa entonces a actuar como una entrada de control. Puede intentar redirigir al asistente de la tarea del usuario hacia la recuperación de datos, la divulgación o una acción no autorizada.
Microsoft anunció protección contra inyección en la bandeja de entrada en Defender for Office 365 durante julio de 2026. La capacidad se lanzó en vista previa pública para clientes elegibles.
Microsoft afirma que el sistema detecta instrucciones maliciosas para IA durante la inspección del flujo de correo. Los mensajes detectados reciben un veredicto de phishing de alta confianza y pueden aislarse antes de llegar a los usuarios o asistentes conectados.
Esta ubicación es importante. Bloquear un ataque antes de la entrega evita que entre en índices de búsqueda del buzón, sistemas de recuperación, resúmenes y contexto de agentes posteriores.
Sin embargo, la detección en la puerta de enlace no puede resolver todos los casos. Un atacante puede colocar instrucciones maliciosas en una cuenta interna comprometida, una lista de distribución permitida, un hilo reenviado o un archivo adjunto.
La distinción entre instrucciones y datos también sigue siendo difícil para los modelos de lenguaje. Ambos llegan como lenguaje natural y ambos pueden contener solicitudes, órdenes citadas o texto procedimental.
Un correo de un responsable puede decir legítimamente: “Revise el archivo adjunto y envíe su respuesta”. Una inyección maliciosa puede utilizar un lenguaje casi idéntico mientras se dirige a la IA en lugar de al empleado.
El asistente debe inferir autoridad, procedencia e intención. La fluidez en lenguaje natural por sí sola no proporciona esas propiedades de seguridad.
Por eso el ataque contra el filtro y el ataque contra el asistente pertenecen a la misma discusión. Ambos explotan la ambigüedad entre contenido mostrado, contenido procesado y contenido autorizado.
Google News puso de relieve una historia sobre defensas de correo impulsadas por IA, pero las implicaciones van más allá de la clasificación de spam. Todo agente conectado a un buzón hereda este problema sin resolver de límites de entrada.
EchoLeak mostró lo que ocurre cuando el correo llega a las herramientas
Un correo oculto se vuelve considerablemente más peligroso cuando un asistente de IA puede recuperar contexto privado y comunicarse más allá del buzón.
La divulgación de EchoLeak en 2025 ofreció una advertencia concreta. Investigadores describieron un ataque en varias fases que involucraba Microsoft 365 Copilot y un correo electrónico cuidadosamente elaborado.
Microsoft identifica EchoLeak como CVE-2025-32711 y afirma que el problema ha sido corregido. La empresa lo describe como una técnica de inyección entre prompts que podría exponer datos limitados ya disponibles para una víctima.
Según la guía de seguridad de IA de Microsoft, un mensaje aparentemente inofensivo podría contaminar el contexto que procesaba Copilot. La técnica podría entonces provocar una divulgación no intencionada en condiciones específicas.
El incidente fue importante porque no dependía de robar primero la contraseña del usuario. Se dirigía al asistente a través de datos que se esperaba que el asistente leyera.
EchoLeak era más complejo que la campaña de text salting destacada por Google News. Involucraba múltiples fases y condiciones, mientras que el text salting buscaba principalmente evadir la clasificación.
Sin embargo, ambos casos cuestionan la misma premisa. El correo electrónico se trata como contenido, aunque partes de ese contenido pueden funcionar como instrucciones adversarias para los sistemas de IA.
El riesgo aumenta con la generación aumentada por recuperación, o RAG. Este diseño recupera información privada relevante y la añade al contexto de un modelo antes de generar una respuesta.
RAG ayuda a un asistente de correo electrónico a responder preguntas sobre proyectos, calendarios, clientes y conversaciones anteriores. También coloca información valiosa cerca de contenido de mensajes controlado por atacantes.
El acceso a herramientas añade otra capa. Un asistente que solo resume puede inducir a error a un usuario, pero un agente con herramientas de mensajería o archivos puede generar consecuencias operativas directas.
Los desarrolladores suelen confiar en un prompt de sistema que indica al modelo que ignore instrucciones maliciosas. Esa medida ayuda, pero no crea un límite de seguridad rígido.
Un desafío de investigación a gran escala llamado LLMail-Inject recopiló 208.095 envíos de ataques de 839 participantes. Los investigadores probaron múltiples defensas, modelos y configuraciones de recuperación en un entorno realista de agentes de correo electrónico.
El volumen de envíos importa porque los atacantes adaptativos no repiten una frase obvia. Exploran transformaciones, encuadres, codificación, contexto social y comportamientos específicos de cada modelo.
Los defensores deberían asumir que cualquier clasificador o protección de prompts puede generar falsos negativos. Las acciones sensibles necesitan controles de autorización independientes que no dependan de la interpretación del modelo.
Un resumidor de correo electrónico no debería obtener permiso para enviar mensajes simplemente porque puede leerlos. El acceso a la búsqueda no debería implicar acceso a todas las carpetas del buzón ni a todos los documentos conectados.
Las llamadas a herramientas deberían aplicar el principio de mínimo privilegio, que concede a cada componente solo los permisos necesarios para su tarea actual. Las acciones de alto impacto deberían requerir confirmación explícita del usuario.
Los equipos de seguridad también necesitan registros que muestren qué mensaje influyó en una salida o acción. Sin procedencia, un responsable de respuesta a incidentes no puede identificar fácilmente la entrada contaminada.
Los usuarios que gestionan material fuente para sistemas de IA afrontan un reto relacionado. Una clara captura de información y la separación de fuentes pueden ayudar a preservar el contexto, pero los permisos a nivel de aplicación siguen siendo esenciales.
La lección de EchoLeak no es que todos los asistentes de correo electrónico sean inseguros. Es que su seguridad debe corresponder a su autoridad, no a su apariencia conversacional.
La disyuntiva defensiva es visibilidad frente a utilidad
Eliminar todos los elementos ocultos reduciría algunos ataques, pero también dañaría correos electrónicos legítimos y dejaría intactos fallos de autorización más profundos.
Un sanitizador estricto podría eliminar CSS, elementos ocultos, recursos remotos y HTML complejo antes de que un sistema de IA leyera un mensaje. Eso reduciría considerablemente la superficie de ataque.
También eliminaría estructuras que ayudan a usuarios y modelos a entender correos legítimos. Las tablas, los diseños adaptables, las citas, las firmas, las etiquetas de accesibilidad y el formato transaccional pueden transmitir significado útil.
Parte del contenido oculto cumple fines operativos. El texto de preencabezado puede ofrecer una breve vista previa en la bandeja de entrada, mientras que los diseños adaptables muestran elementos distintos en pantallas de escritorio y móviles.
Los productos de seguridad deben distinguir esos casos de un bloque grande oculto diseñado para manipular la clasificación. La decisión no puede basarse en una sola propiedad de CSS.
Renderizar cada mensaje dentro de un navegador controlado puede mejorar el análisis de visibilidad. También aumenta los costes de computación e introduce un motor de navegador en la cadena de seguridad.
Una vista renderizada podría aun así no coincidir con todos los clientes. El ancho móvil, el modo oscuro, las imágenes bloqueadas, la configuración de idioma y las preferencias de accesibilidad pueden cambiar el resultado.
La estrategia más segura utiliza varias representaciones. Un sistema puede conservar el contenido sin procesar para análisis forense, calcular una vista normalizada e identificar por separado las regiones ocultas o de baja visibilidad.
El clasificador de IA debería recibir etiquetas explícitas para esas regiones. El material oculto no debería entrar silenciosamente en el mismo flujo de texto indiferenciado que el contenido visible.
Un asistente podría tratar el texto oculto como metadatos no confiables. Podría resumir ese contenido oculto solo cuando el usuario solicite un análisis de seguridad.
Los detectores de inyección de prompts proporcionan otra capa. La implementación de Microsoft inspecciona asuntos, cuerpos de mensajes, HTML, estilos, contenido reenviado y material codificado antes de que un asistente los procese.
No obstante, la detección de inyección de prompts es probabilística. Los correos electrónicos legítimos pueden contener debates sobre prompts, pruebas de seguridad, comandos de automatización o mensajes maliciosos citados.
Un equipo de investigación podría recibir muestras de ataques auténticas por correo electrónico. Un filtro de seguridad podría poner esos mensajes en cuarentena incluso cuando el destinatario los espera.
Los falsos positivos crean presión para debilitar la aplicación de las medidas. Si el correo importante desaparece con demasiada frecuencia, los administradores añaden excepciones que los atacantes pueden estudiar y explotar.
La confirmación humana también es imperfecta. Los usuarios aprueban solicitudes de forma rutinaria cuando una interfaz las presenta como pasos normales, especialmente durante tareas repetitivas.
Por tanto, la confirmación debe explicar la acción propuesta, su destino y los datos implicados. Un mensaje impreciso que pregunta si se desea «continuar» ofrece poca protección.
El diseño más sólido separa el razonamiento del modelo de la aplicación de políticas. El modelo puede sugerir una acción, mientras que un software determinista verifica permisos, destinos, clasificaciones de datos y requisitos de aprobación.
Este enfoque limita el daño tanto de los prompts ocultos como de los errores habituales del modelo. Un asistente manipulado no puede superar los límites aplicados fuera de su contexto lingüístico.
La disyuntiva es una menor comodidad. Los usuarios pueden enfrentarse a más avisos, integraciones más limitadas y una automatización más lenta para tareas de alto riesgo.
Esa fricción está justificada cuando un asistente puede enviar mensajes externos, recuperar documentos confidenciales, modificar registros o iniciar flujos de trabajo financieros. Los resúmenes de bajo riesgo pueden mantener controles más ligeros.
Por tanto, las herramientas de correo electrónico con IA deberían aplicar una autoridad gradual. Leer un mensaje seleccionado, buscar en una carpeta, redactar una respuesta y enviar esa respuesta deberían seguir siendo niveles de permiso separados.
Qué deberían vigilar los equipos de seguridad a continuación
La siguiente fase se medirá por la calidad de detección, el diseño de permisos y la evidencia de abuso en el mundo real, más que por otro benchmark de modelos.
La primera señal es una disponibilidad más amplia de inspección de correo electrónico consciente de la visibilidad. La vista previa pública de Microsoft muestra que la inyección de prompts se está convirtiendo en una categoría diferenciada de seguridad del correo.
Los equipos de seguridad deberían observar cómo los proveedores exponen estas detecciones. Los productos útiles identificarán la región oculta, explicarán su función y preservarán evidencia para la investigación.
Un veredicto genérico de phishing no es suficiente. Los analistas necesitan saber si un mensaje contenía relleno oculto mediante CSS, una instrucción codificada, directivas de herramientas sospechosas o una discrepancia inusual entre el contenido visible y el contenido sin procesar.
La segunda señal es cómo Google, Microsoft y los desarrolladores externos limitan los agentes conectados al buzón. Las actualizaciones de modelos importan menos que los límites aplicables en torno a la recuperación y el uso de herramientas.
Los compradores deberían preguntar si los asistentes distinguen los mensajes externos de las instrucciones internas. También deberían preguntar si el contenido recuperado conserva la identidad del remitente, la ubicación y el nivel de confianza.
Los administradores necesitan controles para acciones específicas. Una política debería permitir la elaboración de resúmenes sin permitir automáticamente el correo saliente, el acceso a archivos, los cambios de calendario o las llamadas a API de terceros.
La tercera señal es evidencia verificada de explotación. Los datos de text salting de Barracuda muestran una implementación a gran escala contra filtros, pero no establecen que todos los mensajes derrotaran un producto basado en LLM.
Los proveedores deberían publicar la metodología y los denominadores cuando sea posible. Los recuentos de detecciones por sí solos no revelan tasas de entrega, clasificaciones exitosas, interacción de las víctimas ni compromiso posterior.
La misma cautela se aplica a las demostraciones de inyección de prompts. Un ataque de laboratorio demuestra que existe una vía de seguridad, pero los controles de producción pueden cambiar su fiabilidad práctica.
A la inversa, la ausencia de incidentes públicos no demuestra seguridad. La manipulación de agentes de IA puede parecerse a la actividad ordinaria de los usuarios, lo que dificulta identificar incidentes sin registros detallados.
Las organizaciones no necesitan esperar mediciones perfectas. Pueden empezar por mapear cada flujo de trabajo que permita a la IA procesar correo electrónico entrante o recuperar contexto del buzón.
Los equipos deberían documentar qué puede leer cada asistente, qué herramientas puede invocar y qué acciones requieren aprobación. También deberían probar mensajes que contengan contenido oculto y fuera de pantalla.
Los ejercicios de seguridad deberían incluir ambas direcciones de ataque. Una prueba debería ocultar contenido de relleno benigno para evadir la clasificación. Otra debería ocultar instrucciones maliciosas destinadas al asistente.
Los desarrolladores deberían evaluar si el sistema explica la incertidumbre. Un asistente que detecta instrucciones conflictivas u ocultas debería detenerse e identificar la fuente sospechosa.
Los usuarios deberían mantener el escepticismo ante las advertencias generadas por IA dentro de los resúmenes de correo electrónico. Una alerta pulida puede originarse en contenido controlado por atacantes incluso cuando la interfaz pertenece a un proveedor de confianza.
Para los flujos de trabajo informativos, mantenga disponibles las fuentes originales e inspeccione las afirmaciones relevantes antes de actuar. Los resúmenes de IA deberían acelerar la revisión, no reemplazar la procedencia.
Google News volvió a centrar la atención en los ataques CSS contra el correo web, pero el problema duradero es mayor que una sola campaña. El correo electrónico ahora transporta contenido para personas, clasificadores, sistemas de recuperación y herramientas autónomas.
Esas audiencias no perciben el mismo mensaje. Hasta que los sistemas de seguridad modelen directamente esa diferencia, los atacantes seguirán aprovechando la brecha entre lo que ven los humanos y lo que leen las máquinas.
