Desde julio de 2025, un grupo criminal ha infectado 953 tiendas online utilizando JavaScript malicioso. La mayoría de las víctimas utilizan Magento, una plataforma popular para el comercio electrónico. La campaña sigue activa y los atacantes cambian de dominio web cada pocos meses para evadir la detección.

Un grupo criminal ha infectado tiendas Magento con JavaScript malicioso desde julio de 2025, y hasta ahora 953 tiendas online se han visto afectadas. La mayoría de las víctimas utilizan Magento, una plataforma popular para crear tiendas en línea.

La campaña sigue activa. Los operadores cambian a un nuevo dominio web cada pocos meses, y el último, deepveindrilling.com, comenzó a cargarse en las páginas de las tiendas en octubre de 2026.

Lo que hace que esta campaña sea difícil de detectar es cómo elige a sus víctimas. El código inyectado no se queda simplemente en una tienda esperando. Antes de hacer cualquier cosa, pregunta a un servidor si el visitante es un comprador real o un escáner automatizado.

Los compradores reales reciben un script, mientras que los escáneres no reciben nada. Un dueño de tienda que realice un escaneo rápido puede ver un resultado limpio incluso cuando la tienda ya está comprometida. Trucos similares han aparecido en otras campañas, como una que utilizaba un truco de SVG onload para ocultar un skimmer en las páginas de pago.

Investigadores de Sansec, una firma de seguridad de comercio electrónico holandesa, identificaron y documentaron este malware en detalle. El equipo forense de Sansec publicó sus hallazgos el 24 de octubre de 2026, y afirmó que el grupo ha atacado 953 tiendas desde julio de 2025.

Su escáner, eComscan, encontró el cargador dentro de la base de datos de 148 instalaciones de servidores a lo largo de la campaña. Los hallazgos completos están disponibles en el informe de investigación de amenazas de Sansec, que enumera los dominios e indicadores.

Infectan 953 tiendas online con JavaScript malicioso

El cargador se aloja en la tabla cms_block, que Magento utiliza para almacenar bloques de contenido estático que aparecen en las páginas de la tienda.

Sansec encontró el dominio más reciente en los bloques de 83 tiendas, casi todas ejecutando Magento. Sesenta de esas 83 tiendas ya habían ejecutado un cargador anterior del mismo grupo, y 34 de ellas habían sido infectadas desde octubre de 2025.

Esto sugiere que muchos comerciantes fueron infectados anteriormente y nunca limpiaron el sistema por completo. El cargador también ha cambiado con el tiempo.

La versión inicial utilizaba un pequeño script para leer un valor almacenado llamado fpCode desde el navegador del visitante y ejecutarlo nuevamente en vistas de página posteriores, incluso cuando el dominio del atacante estaba fuera de línea.

A finales de octubre, los operadores reescribieron el código. La nueva versión envía una huella digital del navegador al servidor. Verifica marcadores de automatización como navigator.webdriver, globales de Selenium y propiedades de ChromeDriver, y también recopila detalles como el nombre de la GPU, el tamaño de la pantalla y la zona horaria.

Al igual que otras campañas de inyección de JavaScript de Magecart, el código depende de scripts ocultos que se mezclan con las páginas normales de la tienda. Las oleadas anteriores dependían de debilidades en la carga de archivos.

En marzo de 2026, el grupo inyectó el cargador en 471 tiendas en solo una hora, después de cargar webshells a través de PolyShell, un fallo de carga de archivos sin restricciones rastreado como CVE-2026-48356.

Sansec también encontró el cargador en 169 instalaciones de Magento 2 a las que les faltaba al menos un parche del núcleo. De esas, 102 también tenían archivos cargados a través de PolyShell o SessionReaper (CVE-2025-54236).

Las tiendas parcheadas tampoco estaban totalmente seguras. Una tienda con una versión actual recibió el cargador una hora después de un escaneo limpio.

Cómo puedes revisar tu tienda si eres propietario

Sansec te aconseja que no confíes únicamente en un escaneo limpio. En su lugar, deberías buscar en las tablas cms_block y cms_page patrones de código como fpCode, se_referrer y localStorage.getItem.

Eliminar el script no quita el acceso del atacante a la base de datos. También deberías revisar la tabla admin_user en busca de cuentas desconocidas, buscar procesos desconocidos y revisar las carpetas de carga como pub/media/custom_options/.

Después de la limpieza, deberías cambiar todas las contraseñas de la base de datos, del administrador y de la API. El parcheo es la otra parte de la solución. La actualización APSB26-73 de Adobe soluciona PolyShell, mientras que APSB25-88 cubre SessionReaper.

SessionReaper es una vulnerabilidad crítica de SessionReaper que permite a los atacantes tomar el control de las cuentas de los clientes. Si no puedes parchear de inmediato, puedes usar un firewall de aplicaciones web para bloquear los intentos de explotación conocidos mientras programas la actualización.