The Magento malware campaign compromised 953 online stores between July 2025 and October 2026, according to Sansec’s October 24, 2026 investigation. The injected JavaScript fingerprints visitors and can withhold its payload from automated scanners, so a clean crawl doesn’t prove a store is safe. Merchants should audit CMS database content, administrator access, API integrations, server persistence and shoppers’ browser storage.
Un cargador de bloques de CMS es código malicioso insertado en contenido de página gestionado mediante una base de datos para que una tienda cargue JavaScript controlado por un atacante. En esta campaña, eliminar el script visible no basta: el acceso persistente al servidor y el código guardado en el navegador localStorage pueden sobrevivir a una limpieza superficial.
¿Qué está haciendo la campaña de malware de Magento?
La campaña de malware de Magento coloca un cargador de JavaScript en el contenido del CMS de Magento o Adobe Commerce, perfila el navegador de cada visitante y sirve código posterior de forma selectiva. Sansec informó el 24 de octubre de 2026 de que la operación había comprometido 953 tiendas desde julio de 2025 y estaba asociada a cinco dominios principales de cargadores.
Sansec encontró el cargador en el cms_block.content campo de la base de datos. Su escáner identificó esa ubicación en 148 instalaciones de servidor en 2026, sin encontrar ningún cargador de la campaña en core_config_data ni en archivos de temas. Los comerciantes no deberían limitar la búsqueda a las plantillas simplemente porque muchas investigaciones antiguas de Magecart comenzaran allí.
El dominio observado más recientemente, deepveindrilling.com, se registró el 6 de octubre de 2026. Las tiendas comenzaron a cargarlo el 7 de octubre, y Sansec registró la primera detección a las 21:54 UTC. Para el 8 de octubre, el rastreador de Sansec había identificado la versión inicial de dos scripts en 74 tiendas; finalmente, el dominio se observó en bloques de CMS de 83 tiendas.
La escala también creció por oleadas. Sansec informó de que lanhd6549tdhse.top se inyectó en 471 tiendas en el plazo de una hora el 30 de marzo de 2026, tras las cargas de webshells PolyShell. Este hallazgo de una única fuente representa aproximadamente el 49.4% del total de la campaña de 953 tiendas: 471 dividido entre 953 y multiplicado por 100.
¿Cómo se oculta el malware a los escáneres de seguridad?
The Magento malware campaign evades scanners by collecting automation signals, WebGL and GPU data, CPU core counts, memory, screen dimensions, time zone, languages and browser client hints. On October 24, 2026, Sansec’s automated Chrome session received an HTTP 200 response but no injected content, demonstrating selective delivery.
El 23 de octubre de 2026, el operador sustituyó la etiqueta de script externo anterior por un cargador de identificación mediante huella digital insertado en línea. Ese día, nueve tiendas adicionales recibieron el cargador y se reescribieron los bloques de CMS infectados anteriormente. Cuando Sansec volvió a rastrear 71 tiendas el 24 de octubre, todas sirvieron la versión revisada.
Por tanto, una respuesta HTTP correcta puede resultar engañosa. La monitorización del estado puede confirmar que un dominio remoto respondió, sin llegar a ver el código mostrado a un comprador aceptado. En mi opinión, tratar un escaneo limpio con un navegador sin interfaz como prueba de la remediación es el atajo más peligroso de este incidente.
Sansec no había capturado, a fecha del 24 de octubre de 2026, la carga útil final enviada a un visitante aceptado por el cargador más reciente. Por tanto, la acción definitiva de la campaña seguía sin verificarse en el momento de la publicación. Calificar la carga útil no visible como un skimmer de pagos, un ladrón de credenciales o un redireccionador confirmado iría más allá de las pruebas disponibles.
¿Por qué puede sobrevivir la infección después de bloquear el dominio?
La campaña de malware de Magento puede persistir en los navegadores de los compradores porque un cargador de octubre de 2026 leía código ejecutable de localStorage.fpCode. Code retained in browser storage can run on later page views after the loader domain is blocked or unavailable, so removing the server-side injection does not erase copies already stored on customer devices.
La versión del 7 de octubre de 2026 colocaba el código almacenado en el controlador onclick de un elemento invisible y lo ejecutaba sin utilizar eval(). Un escáner que busque únicamente llamadas llamativas a eval() podría no detectar este comportamiento. Bloquear el dominio mediante DNS o mediante la Política de seguridad de contenido detiene una vía de entrega, pero no un conjunto de instrucciones ya almacenado en caché.
La Política de seguridad de contenido de Adobe Commerce aún puede proporcionar señales de alerta valiosas. La documentación de Adobe de 2026 indica que Adobe Commerce 2.4.7 y posteriores utiliza el modo restrictivo de forma predeterminada en las páginas de pago y el modo de solo informe en el resto. Sansec informó de que recibió aproximadamente 52.000 informes de CSP relacionados con el dominio anterior de la campaña additionalver.com en 2026.
Esos informes pueden revelar conexiones inesperadas con terceros incluso cuando un rastreador no recibe nada. Los comerciantes deben conservar la telemetría de CSP antes de realizar cambios y, después, comparar las URL afectadas, las marcas de tiempo y los agentes de usuario con los registros de actualización del CMS.
¿Cómo deben investigar y limpiar la infección los comerciantes de Magento?
Los comerciantes de Magento y Adobe Commerce deben conservar las pruebas, buscar en los campos de la base de datos del CMS, identificar los accesos no autorizados y eliminar todos los mecanismos de persistencia antes de rotar las credenciales. Las indicaciones de Sansec de 2026 señalan que eliminar únicamente el JavaScript inyectado no elimina el acceso a la base de datos, las cuentas de administrador fraudulentas, las integraciones de API, los webshells ni las puertas traseras dejadas por el operador.
La siguiente secuencia de respuesta cubre las pruebas específicas de la campaña que los comerciantes deben examinar en 2026:
- Buscar
cms_block.contentycms_page.contentparafpCode,se_referrerylocalStorage.getItem. Incluya las tablas de la base de datos con prefijos personalizados y conserve las filas coincidentes antes de editarlas. - Utilice el valor de
update_timede cada registro del CMS para reconstruir los cambios no autorizados. Correlacione esas horas con los inicios de sesión de administradores, la actividad de despliegue, las llamadas a la API y los registros del servidor. - Inspeccionar
admin_userpara cuentas reactivadas de forma desconocida o inesperada. Revise las integraciones de API y los procesos desconocidos en lugar de asumir que la inyección en la base de datos era el único punto de acceso del atacante. - Busque
accesson.php, GSocket y archivos ejecutables o camuflados enpub/media/custom_options/ypub/media/customer_address/. - Aplique las actualizaciones de seguridad pertinentes de Adobe, complete la limpieza forense y, a continuación, rote las credenciales de la base de datos, de los administradores y de las integraciones de API. Rotarlas antes de eliminar la persistencia podría devolverle credenciales nuevas al atacante.
El estado de los parches requiere matices. Sansec informó en 2026 de que a 169 instalaciones afectadas de Magento 2 les faltaba al menos un parche principal; 102 de esas tiendas, es decir, 60%, también contenían archivos asociados con PolyShell o SessionReaper. Sin embargo, una tienda Magento 2.4.7-p10 sin parches principales pendientes recibió el nuevo cargador el 23 de octubre de 2026, después de detectar un administrador malicioso el 16 de septiembre y una puerta trasera GSocket el 24 de septiembre.
Este caso límite es importante. Un software completamente parcheado puede volver a infectarse cuando un compromiso anterior deja accesos válidos o persistencia en el servidor. Sinceramente, aplicar parches sin investigar las cuentas y los artefactos del sistema de archivos solo tiene sentido como contención temporal, no como una respuesta completada.
¿Qué vulnerabilidades y campañas están relacionadas?
La campaña de malware de Magento presenta vínculos observados con artefactos de compromisos anteriores de PolyShell y SessionReaper, pero es independiente de StyleSmuggler. Adobe publicó la actualización APSB26-73 relacionada con PolyShell el 14 de julio de 2026, mientras que SessionReaper es CVE-2025-54236, una vulnerabilidad con una puntuación CVSS de 9.1 abordada mediante APSB25-88 el 9 de septiembre de 2025.
| Evento | Fecha | Relación con esta campaña | Acción del comerciante |
|---|---|---|---|
| SessionReaper, CVE-2025-54236 | Aviso del 9 de septiembre de 2025 | En la muestra de Sansec de 2026 aparecieron archivos asociados en algunas tiendas afectadas | Verifique la cobertura de APSB25-88 e investigue accesos anteriores |
| PolyShell, CVE-2026-48356 | Actualización del 14 de julio de 2026 | Sansec informó en 2026 de artefactos de webshell y de una inyección rápida del cargador | Instale APSB26-73 y busque indicios de persistencia |
| StyleSmuggler, CVE-2026-75650 | Hotfix del 7 de septiembre de 2026 | Cadena independiente de ejecución remota de código sin autenticación | Aplique su hotfix, pero no lo etiquete como el origen de la campaña del bloque CMS |
| Reescritura del cargador de fingerprinting | 23 de octubre de 2026 | El operador de la campaña añadió una distribución selectiva basada en el navegador | Utilice pruebas de la base de datos, de los accesos y de la CSP, en lugar de basarse únicamente en los resultados de los rastreadores |
Posteriormente, Adobe confirmó la explotación activa de SessionReaper, según su boletín de seguridad APSB25-88. Sansec recomienda instalar APSB26-73 mientras se investiga la campaña más reciente, pero ninguna de las dos actualizaciones elimina las cuentas maliciosas, los registros CMS modificados ni las puertas traseras creadas antes de aplicar los parches.
La primera explotación confirmada de StyleSmuggler tuvo lugar el 4 de septiembre de 2026, y Adobe publicó su hotfix tres días después. Nuestro análisis independiente del zero-day StyleSmuggler de Magento explica esa cadena de explotación. Mezclar los incidentes puede llevar a los equipos de respuesta hacia indicadores equivocados y producir una cronología de la brecha inexacta.
Preguntas frecuentes sobre la campaña de malware de Magento
¿Puede un análisis limpio de Magento demostrar que la tienda es segura?
No. La campaña de malware de Magento ocultó el contenido inyectado al Chrome automatizado de Sansec el 24 de octubre de 2026, aunque devolvió HTTP 200, por lo que, además del análisis del navegador, son necesarias la inspección de la base de datos, la revisión de las cuentas y el análisis forense del servidor.
¿Dónde deben buscar los comerciantes el código malicioso?
Los comerciantes deben buscar cms_block.content y cms_page.content para fpCode, se_referrer y localStorage.getItem, incluidas las tablas de la base de datos con prefijo. Sansec identificó el cargador de la campaña en cms_block.content en 148 instalaciones de servidores en 2026.
¿Bloquear deepveindrilling.com elimina la infección?
No. Bloquear deepveindrilling.com puede detener esa ruta de red, pero el código guardado en el navegador localStorage puede ejecutarse en visitas posteriores, y la tienda puede conservar cuentas maliciosas, acceso a la base de datos o puertas traseras en el servidor.
¿Fue StyleSmuggler responsable de las 953 tiendas comprometidas?
No. StyleSmuggler, identificado como CVE-2026-75650, es una cadena de explotación independiente de septiembre de 2026. La operación que afectó a 953 tiendas, documentada por Sansec el 24 de octubre de 2026, se centra en la inyección recurrente de cargadores en bases de datos de CMS, la entrega selectiva y el acceso persistente.