Campaña de skimming en Magento infecta 953 tiendas con código que esquiva los escáneres
Una operación criminal que lleva desde mediados de 2025 plantando JavaScript malicioso en tiendas Magento ha alcanzado ya las 953 tiendas online y sigue activa. Lo que distingue a esta campaña no es tanto su escala como su técnica: el código inyectado decide, en cada carga de página, si el visitante es un comprador humano o un escáner automatizado, y solo entrega la carga maliciosa a los humanos.
Qué ocurrió
Los atacantes guardan un pequeño loader dentro de la base de datos de Magento, no en un archivo de tema ni de módulo. Reside en la tabla cms_block, donde Magento almacena los bloques de contenido estático que se muestran en las páginas de la tienda. Como el loader forma parte del contenido normal de la página, sobrevive a las comprobaciones de integridad de archivos y a los redespliegues que solo revisan el código.
Antes de hacer nada, el loader contacta con un servidor de distribución de tráfico y pregunta si el visitante actual debe recibir el script real. Los compradores legítimos reciben la carga de skimming; cualquier cosa que parezca un rastreador, un navegador headless o un escáner de seguridad recibe en su lugar una instrucción inofensiva que no hace nada. Un propietario que ejecute un escaneo externo rápido verá a menudo un resultado limpio en una tienda que ya está comprometida.
El grupo rota su infraestructura cada pocos meses. El dominio en uso desde octubre de 2026 se encontró en los bloques de contenido de 83 tiendas. De ellas, 60 ya habían ejecutado antes un loader más antiguo de los mismos operadores y 34 habían estado infectadas de forma intermitente desde octubre de 2025. Es decir, muchos comercios ya habían sido atacados, "limpiaron" el script visible y volvieron a infectarse porque el acceso subyacente nunca se eliminó.
El propio loader ha evolucionado. La primera versión leía un valor almacenado llamado fpCode en el almacenamiento del navegador del visitante y lo volvía a ejecutar en páginas posteriores, lo que mantenía vivo el skimmer incluso cuando el dominio del atacante estaba fuera de línea. A finales de octubre, los operadores lo reescribieron para enviar una huella completa del navegador a su servidor: comprueba marcadores de automatización como navigator.webdriver, variables globales de Selenium y propiedades de ChromeDriver, y recopila el nombre de la GPU, el tamaño de pantalla y la zona horaria para distinguir navegadores reales de entornos de prueba.
Cómo se vulneraron las tiendas
Se trata de una inyección al estilo Magecart, y el acceso inicial ha llegado sobre todo a través de fallos de subida de archivos en Magento. En marzo de 2026, el grupo inyectó el loader en 471 tiendas en una sola hora tras colocar web shells mediante PolyShell, la vulnerabilidad de subida de archivos sin restricciones identificada como CVE-2026-48356.
El loader también apareció en 169 instalaciones de Magento 2 a las que les faltaba al menos un parche de seguridad del núcleo. 102 de ellas mostraban además archivos subidos mediante PolyShell o mediante SessionReaper (CVE-2025-54236), un fallo crítico que permite secuestrar sesiones de clientes. Las tiendas completamente parcheadas tampoco fueron inmunes: una tienda con una versión actual recibió el loader una hora después de que un escaneo saliera limpio, lo que apunta a credenciales robadas o puertas traseras residuales más que a un exploit nuevo.
Por qué importa
Los skimmers de checkout roban los números de tarjeta directamente desde el navegador del cliente, así que el comercio suele enterarse por las redes de tarjetas o por clientes enfadados, no por su propia monitorización. Esta campaña lo empeora porque derrota activamente la única comprobación en la que confían la mayoría de los propietarios: un escaneo externo de la tienda. Un resultado limpio de una herramienta automatizada ya no demuestra que una tienda Magento sea segura.
Las cifras de reinfección son la otra señal de alarma. Eliminar un script inyectado sin cerrar el agujero por el que entró, y sin rotar las credenciales que el atacante ya posee, compra unas pocas semanas como mucho.
Qué hacer
Si gestionas una tienda Magento, trata lo siguiente como una lista de comprobación, no como una sugerencia:
- Busca en la base de datos, no solo en los archivos. Consulta las tablas
cms_blockycms_pageen busca de patrones comofpCode,se_referrerylocalStorage.getItem. Revisa en concretocms_block.content. - Comprueba la persistencia. Revisa la tabla
admin_useren busca de cuentas que no reconozcas, busca procesos desconocidos en el servidor e inspecciona directorios de subida comopub/media/custom_options/en busca de web shells. - Rota todo. Tras la limpieza, cambia las credenciales de la base de datos, del administrador y de las API. Borrar el script no revoca el acceso del atacante.
- Parchea. El boletín APSB26-73 de Adobe corrige PolyShell y el APSB25-88 cubre SessionReaper. Si no puedes actualizar de inmediato, coloca un firewall de aplicaciones web delante de la tienda para bloquear los intentos de explotación conocidos mientras tanto.
- Prueba como un humano. Al verificar una tienda, usa una sesión de navegador normal con el almacenamiento habilitado, no solo un escáner headless, y compara los scripts que recibe un visitante real con lo que ven tus herramientas.
Indicadores a vigilar (defanged)
- Dominio del loader:
deepveindrilling[.]com(rutas/?s=d35c5031y/?s=49b7ca5f&fp=) - Dominios de distribución de tráfico:
additionalver[.]com,lanhd6549tdhse[.]top,neswnsssn[.]click,manulfie[.]click,hdfdsi84j3h[.]top,c85grt98sd[.]com - Hosts de carga maliciosa vistos en diciembre de 2025:
leqdger[.]click,crypto-insider[.]top - Respuesta señuelo servida a los escáneres:
QWE=123; - Claves del almacenamiento del navegador:
fpCode,136c1e07507f4a97,136c1e07507f4a98
Campañas como esta entran por fallos conocidos y parcheables y luego confían en que nadie mire de cerca. Nuestro servicio de escaneo de vulnerabilidades revisa las plataformas de comercio electrónico precisamente para esta clase de exposición, desde boletines de seguridad de Magento sin aplicar hasta rutas de subida con permisos de escritura, para cerrar la brecha antes de que otro la encuentre.