Cloudflare Client-Side Security detectó ocho cargas útiles que los escáneres públicos no identificaron
Cloudflare Client-Side Security detectó ocho cargas útiles maliciosas en cuatro campañas contra tiendas online, pese a que los servicios públicos de escaneo ofrecían pocas o ninguna advertencia. Las páginas afectadas seguían cargando, mostrando productos y procesando interacciones de los clientes. Bajo esa experiencia aparentemente normal, JavaScript redirigía créditos de afiliación, ocultaba solicitudes de red, interfería con la analítica y creaba un canal para código remoto.
Cloudflare reveló los hallazgos el 16 de septiembre de 2026. Su afirmación central cuestiona una premisa de seguridad conocida: un escaneo limpio no significa que una sesión de navegador se esté comportando de forma segura. Siete cargas útiles no figuraban en VirusTotal cuando Cloudflare las revisó, mientras que urlscan.io no emitió ningún veredicto malicioso para ninguna de las ocho.
La comparación es importante, pero requiere contexto. VirusTotal y urlscan.io proporcionan información valiosa basada en archivos, URL, motores y comportamientos observables enviados. Cloudflare, en cambio, encontró estos scripts dentro de tráfico web activo y analizó su estructura interna. La discrepancia revela una brecha de cobertura entre revisar un artefacto una vez y observar continuamente cómo el código llega a navegadores reales.
Cuatro campañas volvieron el tráfico normal de tiendas online contra los comerciantes
El hallazgo de Cloudflare importa porque estas campañas atacaban las operaciones de ingresos sin necesariamente interrumpir el proceso de pago ni dejar un sitio web fuera de servicio.
Los hallazgos de cuatro campañas de la empresa abarcan robo de afiliación, manipulación de clics, carga de código remoto, interferencia con analítica y seguimiento de visitantes. Cloudflare afirma que su sistema automatizado detectó las cargas útiles antes de que los analistas humanos las investigaran.
La primera operación apuntaba a compradores móviles durante periodos seleccionados. Esperaba a que aparecieran elementos de productos que cumplían ciertos criterios, interceptaba el clic de un comprador y abría una página seleccionada por el atacante en otra pestaña. Mientras tanto, la pestaña original recorría una ruta de seguimiento de afiliación antes de regresar a la tienda.
Ese desvío podría atribuir el crédito a un afiliado que nunca remitió al cliente. El comerciante podría entonces pagar una comisión inmerecida o negar crédito al socio legítimo. El cliente podría no darse cuenta porque la tienda seguía funcionando.
Cloudflare encontró cinco versiones relacionadas en esta operación. Dos estaban activas cuando fueron capturadas, mientras que tres estaban pausadas. Las variantes activas comprobaban el tipo de dispositivo, la hora local, el estado del navegador, la disponibilidad de productos y la ejecución reciente antes de hacer algo visible.
Las versiones posteriores almacenaban un periodo de espera de tres días en el localStorage del navegador, un área de almacenamiento persistente disponible para los scripts de sitios web. Una vez activado, el malware permanecería silencioso en ese dispositivo durante días. Por tanto, un escáner que repitiera la misma visita podría no observar nada inusual.
La segunda operación eliminaba incluso la necesidad de un clic del comprador. Su script emitía una solicitud de afiliación mediante un iframe fuera de pantalla, que es una página incrustada oculta fuera del diseño visible. Un enlace oculto podía hacer clic en sí mismo cuando fallaba el método principal.
El código contactaba primero con un servicio de geolocalización por IP, pero ignoraba los datos geográficos devueltos. Si esa solicitud fallaba, el malware se detenía. Cloudflare no pudo determinar si este comportamiento era una evasión deliberada de entornos aislados o lógica residual.
La tercera operación era más amplia. Un script incrustado directamente en el HTML de un comerciante contenía módulos antiguos de secuestro de búsquedas junto con telemetría activa y funciones de carga remota. Podía solicitar nuevo JavaScript a servidores controlados por atacantes después de que cargara la página.
Esto creó una puerta trasera en la tienda online. El script inicial no necesitaba contener la acción final porque un servidor remoto podía cambiar su respuesta. Cloudflare no pudo determinar qué cargas útiles de segunda etapa entregaron los atacantes en la práctica.
La cuarta operación apuntaba a visitantes móviles que llegaban a través de campañas pagadas. Intentaba desactivar nueve herramientas de analítica o monitorización, ocultar interfaces de atención al cliente, sustituir identidades publicitarias y transmitir telemetría.
El script comprobaba si la ventana gráfica tenía menos de 477 píxeles de ancho. También buscaba etiquetas de campaña seleccionadas durante las dos primeras cargas de página del visitante. Una lista de 325 subcadenas de IP le ayudaba a evitar redes asociadas con analistas o infraestructura automatizada.
Estas operaciones no compartían un único dominio, firma ni estrategia de monetización. Su característica común era la ejecución selectiva. Cada script esperaba un estado del navegador que era poco probable que una inspección automatizada breve reprodujera.
Por qué un escaneo limpio nunca fue suficiente
El conflicto principal es la visibilidad continua del navegador frente al escaneo en un momento concreto, no el aprendizaje automático frente a todos los controles de seguridad existentes.
Los escáneres tradicionales responden preguntas útiles pero limitadas. ¿Alguien ha enviado antes este archivo? ¿Un motor reconoce su firma? ¿Una visita controlada desencadena un comportamiento observable? Estas preguntas se vuelven menos fiables cuando el malware decide qué visitantes pueden ver su lógica real.
Según los informes, un ejemplo de Cloudflare permaneció indexado en urlscan.io sin clasificación durante casi dos años y medio. Su familia de malware más amplia ya estaba documentada, pero esa carga útil específica no había recibido la misma etiqueta práctica.
Un rastreador estático puede cargar la página, inspeccionar sus archivos y registrar el tráfico de red. Sin embargo, el resultado representa una configuración de navegador en un momento determinado. El malware de tiendas online puede comprobar la hora, el dispositivo, la ubicación, el referente, las cookies, el ancho de pantalla y el historial de sesión antes de activarse.
El secuestrador de afiliación nocturno vigilaba mosaicos de productos creados después de la carga inicial de la página. Utilizaba MutationObserver, una interfaz del navegador que detecta cambios en la estructura documental de la página. Un rastreador que capturara solo el HTML original podría no detectar el elemento intervenido.
El ocultador móvil de campañas pagadas fue más allá. Rechazaba redes empresariales, proveedores de nube, instalaciones de alojamiento, VPN, proxies, salidas de Tor y varias ubicaciones geográficas. Estas comprobaciones excluyen de manera desproporcionada los entornos que investigadores y escáneres automatizados suelen utilizar.
Esto genera una inversión incómoda. Una prueba limpia desde un equipo de escritorio en una red corporativa puede convertirse en evidencia de que la lógica de evasión está funcionando. El comerciante observa analítica normal porque la rama maliciosa nunca se ejecuta para las personas que la investigan.
Las campañas también muestran por qué la salud operativa de un sitio web puede resultar engañosa. La monitorización de disponibilidad confirma que las páginas responden. Las pruebas sintéticas de pago confirman que una transacción se completa. Ninguna de las dos comprobaciones revela necesariamente quién recibe la atribución ni qué conexiones del navegador se producen.
Los registros del lado del servidor presentan otra visión parcial. Un script de terceros se ejecuta con acceso al documento de la página y al contexto del navegador. Los riesgos de scripts de terceros de OWASP incluyen la pérdida de control de cambios, la ejecución arbitraria de código y la divulgación de datos sensibles.
La evidencia de Cloudflare no vuelve obsoletos a los escáneres públicos. Los artefactos enviados, las observaciones históricas, los datos de reputación y los indicadores compartidos siguen siendo esenciales para las investigaciones. Los hallazgos muestran, en cambio, que esos sistemas no pueden etiquetar código que nunca reciben ni comportamiento que nunca activan.
La postura defensiva más sólida combina múltiples perspectivas. Los servicios de reputación pueden identificar infraestructura conocida. El análisis de código puede examinar la intención. La telemetría del navegador puede revelar recursos cargados y conexiones. Posteriormente, los analistas humanos pueden determinar si un veredicto automatizado encaja con el contexto operativo.
Ese modelo por capas presiona a los equipos de seguridad que aún tratan un escaneo único como una aprobación definitiva. También presiona a los equipos de marketing y comercio porque sus gestores de etiquetas suelen controlar código que los equipos de seguridad rara vez revisan de forma continua.
Cómo Cloudflare Client-Side Security interpreta JavaScript evasivo
Cloudflare Client-Side Security se centra primero en la estructura del código y, después, utiliza modelos de lenguaje y revisión humana para reducir los hallazgos inciertos.
El clasificador de primera línea de Cloudflare es una red neuronal de grafos, o GNN. Este modelo de aprendizaje automático procesa relaciones entre elementos conectados. En este caso, esos elementos proceden del árbol de sintaxis abstracta de JavaScript, que representa el código como operaciones estructuradas en lugar de texto sin procesar.
Esa distinción ayuda al modelo a mirar más allá de los cambios superficiales. Los atacantes pueden renombrar variables, minificar archivos, rotar cadenas o añadir ramas sin usar. Esos cambios modifican el texto visible, pero pueden preservar las relaciones entre llamadas, condiciones, eventos de página y solicitudes de red.
Cloudflare afirma que su GNN marcó las ocho cargas útiles en tráfico activo. La empresa describió anteriormente la arquitectura de detección más amplia como una cascada, en lugar de un único modelo que toma todas las decisiones.
La GNN está ajustada para detectar estructuras sospechosas. Los scripts que considera benignos salen pronto del proceso. Los scripts potencialmente maliciosos reciben una segunda evaluación de un modelo de lenguaje más pequeño que se ejecuta mediante Workers AI.
Esta segunda etapa aborda el problema de los falsos positivos. Los paquetes publicitarios legítimos, los desafíos contra bots, los scripts de seguimiento y los frameworks comprimidos pueden parecer código malicioso. Pueden utilizar ofuscación, ejecución dinámica, llamadas de red inusuales u otros patrones que parecen sospechosos sin contexto.
Cloudflare informó en una actualización anterior de producto que sus sistemas evalúan 3.500 millones de scripts al día. También indicó que una zona empresarial media expone unos 2.200 scripts únicos. Aproximadamente un tercio puede cambiar en un periodo de 30 días, según la empresa.
Estas cifras proceden de Cloudflare y no han sido auditadas de forma independiente para esta divulgación de campaña. Sin embargo, ilustran el reto operativo. Incluso una baja tasa de falsos positivos se vuelve inmanejable cuando se aplica a miles de millones de evaluaciones.
En la investigación más reciente, Cloudflare afirma que menos del 0,3 por ciento del tráfico analizado llegó a la fase de revisión por modelo de lenguaje. Si ese modelo corroboraba la GNN, el sistema alertaba al cliente.
Las muestras más complejas recibieron otra capa de análisis. Cloudflare utilizó modelos de unas seis familias como “profesores” independientes. Cada uno examinó el mismo script en una sesión nueva y podía acceder a un evaluador restringido de JavaScript.
Los modelos votaron entre cuatro etiquetas: benigno, robo de datos de pago, otro malware y criptominería. Cloudflare ponderó esos votos mediante clasificaciones externas del rendimiento de los modelos. Revisores humanos examinaron los scripts etiquetados como maliciosos o que no alcanzaban una mayoría de dos tercios.
No se trata de un ciclo completamente autónomo. Cloudflare reconoce que la retroalimentación para el entrenamiento de la GNN sigue siendo parcialmente manual. La empresa también planea añadir Cloudflare Sandbox para un análisis más profundo en entornos aislados.
El enfoque combina clasificación estructural, revisión semántica, desacuerdo entre modelos y criterio de analistas. Su ventaja no es que un modelo de lenguaje de algún modo “comprenda” todos los ataques. La ventaja es que cada etapa aborda un modo de fallo distinto.
La GNN puede reconocer similitudes estructurales a gran escala. El modelo de lenguaje puede filtrar JavaScript extraño pero legítimo. Varios modelos profesores pueden revelar incertidumbre. Los analistas pueden investigar el conjunto más reducido en el que las señales automatizadas siguen siendo preocupantes o están divididas.
La monitorización continua aporta el contexto necesario para emitir esos juicios. La documentación de seguridad de Cloudflare indica que el servicio observa los scripts, las conexiones y las cookies que cargan los visitantes. Las funciones avanzadas añaden detección de scripts maliciosos, alertas de cambios de código y reglas de seguridad de contenido.
Esa arquitectura responde directamente al principal desafío. Las herramientas puntuales inspeccionan una muestra o sesión elegida. Los informes continuos del navegador registran cómo aparecen los recursos durante visitas reales, aumentando la probabilidad de que el malware selectivo acabe revelándose.
El navegador se ha convertido en parte del sistema de ingresos
Estos ataques muestran que la seguridad del lado del cliente ahora protege la atribución, la analítica y el acceso de los clientes, además de los datos de pago.
Las dos primeras campañas se dirigían a la economía de los afiliados, no a los números de tarjetas. La distinción importa porque muchos programas de seguridad de tiendas concentran sus controles más estrictos en el proceso de pago. Los ingresos pueden seguir filtrándose antes, durante el recorrido del cliente.
Los sistemas de afiliación determinan qué socio recibe el crédito por una compra. Los atacantes no necesitan detener la transacción si pueden modificar esa decisión. Una solicitud de atribución fraudulenta puede convertir una venta legítima en una comisión inmerecida.
La maniobra de doble pestaña de la primera campaña preservaba el flujo de compra del cliente. Una pestaña mantenía al visitante interactuando mientras la otra pasaba por la ruta de seguimiento del atacante. El ataque se beneficiaba de parecer un evento de navegación normal.
La variante sin clic era aún más discreta. Un iframe invisible podía emitir una solicitud de afiliado sin una interacción significativa del cliente. Cloudflare confirmó las solicitudes automatizadas, pero no estableció si generaron comisiones pagadas.
Esa limitación debe seguir siendo visible. El código puede demostrar intención y capacidad sin probar un daño financiero materializado. Harían falta registros de atribución del comerciante, datos de cuentas de afiliados e historiales de pagos para medir la pérdida real.
El cloaker para móviles de pago se dirigía a otro activo empresarial: la observabilidad. Se centraba en el tráfico que los comerciantes ya habían adquirido mediante búsqueda pagada, campañas de texto y otros canales etiquetados. Esas sesiones eran valiosas precisamente porque el gasto de adquisición las había llevado a la tienda.
El malware intentaba sustituir identificadores de analítica mientras desactivaba herramientas de monitorización y soporte. Si tenía éxito, podía corromper los informes de campaña y hacer que el tráfico legítimo pareciera pertenecer a otro lugar.
También suprimía los controles de chat y contacto. Un comprador que detectara algo inusual podía perder la vía más sencilla para comunicarlo. El comerciante perdería entonces tanto telemetría como comentarios directos de los clientes.
Las pruebas de sandbox de Cloudflare confirmaron que se cargó un script de analítica de sustitución y que activó un beacon de seguimiento. Sin embargo, la empresa no demostró que los atacantes capturaran telemetría utilizable ni desviaran ingresos publicitarios.
La puerta trasera de la tienda presentaba un riesgo distinto. Una vez que el script podía cargar JavaScript remoto arbitrario, las opciones del atacante ya no estaban limitadas a los módulos observados. Las instrucciones futuras podían cambiar sin otra modificación del HTML del comerciante.
Esta flexibilidad complica la delimitación de los incidentes. Eliminar una redirección visible no demuestra que el atacante careciera de otras capacidades. Los equipos de respuesta deben identificar la vía de inserción inicial, los endpoints remotos, las sesiones afectadas y cualquier compromiso administrativo.
Cloudflare no pudo determinar cómo entró ese script en el HTML del comerciante. Identificó credenciales comprometidas, cambios no autorizados en plantillas y temas o plugins infectados como rutas plausibles, no como causas confirmadas.
Esa incertidumbre importa para la remediación. Bloquear un dominio observado puede detener una vía de entrega y dejar abierta la ruta de acceso original. Una respuesta duradera requiere revisar las credenciales, verificar la integridad de las plantillas, inventariar las dependencias y examinar los permisos del gestor de etiquetas.
La industria ya reconoce que el navegador forma parte del límite de seguridad de los pagos. La guía sobre páginas de pago del PCI Security Standards Council se centra en autorizar scripts, verificar su integridad y monitorizar las páginas para detectar cambios no autorizados.
Las campañas de Cloudflare amplían la razón operativa para realizar ese trabajo. El navegador no se limita a mostrar un formulario de pago. Asigna crédito de marketing, registra comportamientos, carga herramientas de soporte y determina qué servicios externos reciben datos de clientes.
Por tanto, los equipos de seguridad, marketing, comercio y analítica comparten la misma superficie de ataque. Una etiqueta de marketing aprobada para medición puede convertirse en una vía de entrega. Un tema comprometido puede convertirse en un canal de mando. Un mecanismo de atribución puede convertirse en un objetivo de robo.
Ese solapamiento genera presión organizativa. Los equipos de seguridad necesitan visibilidad de los cambios en el navegador, mientras que los equipos de marketing necesitan un proceso de revisión que no paralice cada campaña. El problema difícil consiste en gobernar scripts que evolucionan rápidamente sin hacer inviables las operaciones normales de una tienda.
Los hallazgos de Cloudflare aún requieren una lectura cuidadosa
La evidencia de las campañas respalda la monitorización continua, pero no valida de manera independiente todas las afirmaciones sobre el producto ni cuantifica las pérdidas finales de los comerciantes.
Cloudflare descubrió las muestras, operó el sistema de detección y publicó el análisis técnico. Eso da a la empresa acceso directo a telemetría valiosa. También significa que la comparación central de rendimiento procede del proveedor que vende el servicio de detección avanzada.
La divulgación enumera ocho cargas útiles y explica su comportamiento, pero no revela las identidades de los comerciantes afectados. Esa decisión protege a las víctimas y evita crear una nueva lista de objetivos. También limita la verificación independiente de las consecuencias financieras y operativas de los incidentes.
Cloudflare no publicó un benchmark controlado que comparara su sistema con todos los escáneres en condiciones idénticas. Su evidencia muestra que VirusTotal no tenía siete cargas útiles y que urlscan.io no emitió veredictos maliciosos. Eso es más limitado que demostrar una detección superior en todo el mercado.
La ingestión también difiere de la clasificación. Un servicio no puede etiquetar un archivo que nunca ha recibido. Cloudflare observó los scripts porque el tráfico afectado pasó por su red y su flujo de informes del navegador. Esa ventaja de acceso es distinta de la precisión del modelo.
La única carga útil ya conocida por VirusTotal complica aún más una narrativa simple de ganadores y perdedores. El historial público no reveló cuándo apareció el veredicto malicioso. Por tanto, el registro disponible no puede establecer qué sistema la identificó primero.
Los falsos negativos merecen atención, pero también los falsos positivos. Un sistema que marca JavaScript desconocido con demasiada agresividad puede saturar a los analistas o bloquear comercio legítimo. Cloudflare utiliza un modelo de lenguaje adicional, en parte porque el código benigno suele parecerse estructuralmente al malware.
Cloudflare informó anteriormente de reducciones sustanciales de falsos positivos tras añadir esa segunda etapa. Esos resultados fueron evaluaciones internas, no una evaluación independiente revisada por pares. Los clientes deberían juzgar la calidad de las alertas frente a sus propias poblaciones de scripts y resultados de incidentes.
La canalización de modelos también contiene decisiones humanas. Los umbrales de decisión determinan qué scripts avanzan. Los prompts moldean la revisión del modelo de lenguaje. Los pesos de clasificación de modelos influyen en los votos de los evaluadores. Los analistas humanos resuelven casos seleccionados y devuelven etiquetas al entrenamiento.
Esas decisiones no invalidan los hallazgos. Muestran por qué «la IA lo detectó» es una explicación incompleta. La calidad de la detección depende de la telemetría, el diseño del modelo, los umbrales, la revisión de analistas y el proceso de respuesta posterior a una alerta.
La Content Security Policy, o CSP, sigue siendo otra capa importante. La CSP indica a los navegadores qué recursos y conexiones debería permitir una página. Su modo de solo informe puede recopilar infracciones antes de aplicar medidas, como se describe en la referencia de informes de CSP.
Sin embargo, informar por sí solo no bloquea código malicioso. Una lista de permitidos demasiado amplia puede autorizar a un proveedor comprometido. Una inserción directa desde un origen ya confiable también puede eludir simples restricciones de dominio.
La aplicación estricta introduce su propio coste operativo. Las tiendas modernas cargan servicios de publicidad, experimentación, pagos, personalización, soporte y analítica. Sus dominios y código pueden cambiar con frecuencia, lo que dificulta mantener políticas restrictivas.
Subresource Integrity puede verificar que un archivo cargado remotamente coincida con un hash aprobado. Funciona mejor con recursos estables. Se vuelve más difícil cuando un proveedor cambia intencionadamente los scripts sin publicar archivos fijos y versionados.
La conclusión práctica no es que un control sustituya a todos los demás. La observación continua, el inventario de scripts, las comprobaciones de integridad, la CSP, la inteligencia de reputación y la respuesta a incidentes cubren cada uno brechas diferentes.
La evidencia más sólida de Cloudflare se refiere al malware selectivo encontrado en su propia telemetría. Las áreas no demostradas abarcan el robo de ingresos materializado, la actividad de segunda fase, el acceso inicial y el rendimiento frente a ataques no observados. Esos límites deberían orientar cualquier decisión de compra o despliegue.
Tres señales mostrarán si la detección continua cumple
La próxima prueba es si Cloudflare puede convertir estos hallazgos en detección repetible, evidencia más clara y una respuesta más rápida de los comerciantes.
La primera señal es una validación técnica más amplia. Los investigadores de seguridad pueden utilizar los indicadores publicados para buscar infraestructura y código relacionados en otros entornos. Descubrimientos adicionales mostrarían si las cuatro operaciones fueron compromisos aislados o partes de campañas más amplias.
El análisis independiente también podría confirmar el comportamiento de atribución de los scripts, las rutas de carga remota y las barreras antianálisis. Si los investigadores reproducen esos hallazgos, la interpretación de Cloudflare se fortalece. Si descubren explicaciones benignas o resultados diferentes, la confianza debería reducirse.
La segunda señal es la calidad de detección después de que Cloudflare amplíe su flujo de trabajo de sandbox. La ejecución aislada del navegador podría aportar evidencia más sólida sobre el comportamiento de las cargas útiles, al tiempo que protege los sistemas de producción. También podría revelar qué sospechas de los modelos fracasan durante las pruebas en tiempo de ejecución.
Los informes útiles incluirían precisión de alertas, ataques confirmados por analistas, anulaciones y casos omitidos. Las cifras agregadas deberían separar el tráfico analizado de los scripts únicos, porque la ejecución repetida puede distorsionar las mediciones de rendimiento.
Los clientes deberían vigilar la calidad de las explicaciones, no solo el total de alertas. Una advertencia útil debería identificar la ruta de código que la activó, la conexión observada, las páginas afectadas y el estado relevante del navegador. Una etiqueta genérica de contenido malicioso crea trabajo sin orientar la contención.
La tercera señal es el tiempo de respuesta del comerciante. Una alerta técnicamente correcta tiene un valor limitado si permanece sin ver, carece de responsable o no puede desencadenar una investigación coordinada. Los equipos de tiendas necesitan una ruta desde la evidencia del navegador hasta la contención.
Ese proceso debería identificar quién puede desactivar una etiqueta, revocar credenciales, restaurar una plantilla, bloquear un endpoint y validar la analítica posteriormente. También debería preservar la evidencia necesaria para determinar si se vieron afectadas las comisiones, los datos de clientes o las mediciones de campañas.
La monitorización continua se vuelve más convincente cuando acorta el intervalo entre la primera ejecución maliciosa y su eliminación satisfactoria. Se vuelve menos convincente si los equipos reciben alertas, pero no pueden distinguir un compromiso real de cambios rutinarios en los scripts.
Los propietarios de tiendas deberían plantearse una pregunta directa: ¿pueden sus controles actuales explicar qué JavaScript llegó a un cliente real, qué hizo ese código y a dónde se conectó? Un escaneo limpio no puede responder las tres.
Cloudflare Client-Side Security ofrece un enfoque para lograr esa visibilidad, respaldado por una divulgación del proveedor con detalles técnicos. La evidencia merece atención, pero los compradores aún deberían evaluar la calidad de las alertas y la integración de la respuesta dentro de sus propias tiendas digitales.
La medida inmediata va más allá de adquirir un producto. Haga un inventario de los scripts del navegador, revise la autoridad del gestor de etiquetas, pruebe las políticas de generación de informes y defina quién es responsable de las alertas del lado del cliente. Después, mida si esos controles detectan comportamientos que los análisis convencionales de disponibilidad y vulnerabilidades dejan sin identificar.
