953 tiendas afectadas por loader externo en bloques CMS de Magento y fingerprinting

Un actor desconocido ha comprometido al menos 953 tiendas online —la mayoría basadas en Magento— en una campaña persistente que Sansec, la firma neerlandesa de seguridad en comercio electrónico, rastrea desde julio de 2025. Hecho confirmado: los atacantes insertan un fragmento de código en los bloques CMS de Magento que carga un “loader” JavaScript externo; ese loader consulta al servidor del atacante qué hacer a continuación y diferencia entre navegadores de compradores reales y escáneres de seguridad para esconderse de análisis automatizado.

La técnica central aprovecha el uso legítimo de la tabla cms_block (y potencialmente cms_page) de Magento para renderizar contenido estático en la tienda. Cuando el bloque malicioso se muestra en una página visitada por un comprador, el navegador solicita al dominio atacante el script. Sansec ha identificado al menos cinco dominios asociados durante el tiempo de la campaña —manulfie[.]click (julio 2025), neswnsssn[.]click (diciembre 2025), lanhd6549tdhse[.]top (marzo 2026), additionalver[.]com (junio 2026) y deepveindrilling[.]com (octubre 2026)— y reporta que el dominio más reciente responde únicamente a peticiones de scripts originadas por visitantes reales y está protegido por Cloudflare. Estos dominios actúan como etapas del loader; en algunos casos el código externo persiste en el navegador mediante localStorage y en otros incorpora huellas digitales del navegador (fingerprinting) para filtrar bots y escáneres.

Confirmado también: existen dos versiones observadas del loader. Una almacena la carga en localStorage para ejecutarla en visitas posteriores aunque el dominio atacante desaparezca. La segunda añade comprobaciones de fingerprinting para garantizar exposición solo a personas reales. Sansec no ha confirmado cuál es la carga final en producción; el propósito técnico del vector apunta a ejecutar código controlado por el atacante dentro del navegador del comprador, lo que en escenarios precedentes suele emplearse para desviar datos de pago (card-skimming), redirecciones maliciosas o para servir posteriores etapas de explotación.

Sobre el acceso inicial, Sansec estima que 471 de las tiendas fueron inyectadas aprovechando la vulnerabilidad conocida como PolyShell (CVE-2026-48356) y que otras 102 recibieron cargas de archivos mediante PolyShell o SessionReaper (CVE-2025-54236). Las pruebas de campo incluyen hallazgos como webshells disfrazadas de imágenes PNG en directorios públicos de Magento junto a un loader en un bloque CMS; en ese caso la tienda seguía sin aplicar la corrección APSB26-73 de Adobe. Adobe publicó un parche para PolyShell en su boletín de seguridad APSB26-73 (ver Adobe APSB26-73) y los CVE asociados están referenciados públicamente (por ejemplo, en el NVD: CVE-2026-48356 y CVE-2025-54236).

En al menos un caso documentado, una tienda con el núcleo de Magento actualizado fue comprometida creando una cuenta administrativa maliciosa y usando ese acceso para inyectar el código en sus bloques CMS, lo que indica que no todos los compromisos dependen de vulnerabilidades sin parchear: credenciales débiles o controles administrativos insuficientes también son vectores reales. Sansec recomienda auditar cuentas administrativas y bloques CMS; esa guía práctica coincide con las mejores prácticas de seguridad para tiendas Magento.

Otro aspecto técnico relevante es el uso de sistemas de distribución de tráfico (TDS). Iteraciones tempranas del ataque emplearon Keitaro —una plataforma de tracking/analítica publicitaria— como TDS para decidir, según los atributos del visitante, si devolver una carga útil, una redirección o no responder. Sansec describió un comportamiento de prueba: al solicitar additionalver[.]com como si fuera un cliente Windows de escritorio, la respuesta fue “QWE=123;” —solo una cookie que marca al visitante por 24 horas—; deepveindrilling[.]com, más reciente, integró la lógica de filtrado en el loader y eliminó la dependencia de Keitaro.

Impacto y riesgos prácticos: las tiendas afectadas arriesgan exfiltración de datos de pago si la carga final fuera un skimmer; la persistencia en localStorage permite re-execución incluso si el dominio atacante es derribado, dificultando la limpieza completa. Para compradores, el riesgo es la posible captura de números de tarjeta, credenciales o redirecciones a sitios de fraude. Para el ecosistema del comercio electrónico, la combinación de evasión de escáneres, rotación de dominios y mezcla de vectores (vulnerabilidades sin parchear, cuentas comprometidas y webshells) dificulta la respuesta y prolonga la ventana de exposición.

Hechos no confirmados o inciertos: Sansec no ha publicado la naturaleza exacta de la carga final observada en producción ni si todas las tiendas recibieron la misma variante. Tampoco hay confirmación pública de terceros sobre campañas de robo de tarjetas vinculadas a estos dominios específicos, y no se han detallado indicadores de compromiso (IOCs) completos en el reporte resumido. Además, aunque se observó explotación en tiendas mediante PolyShell y SessionReaper, la proporción precisa entre compromisos por vulnerabilidad y compromisos por credenciales robadas sigue siendo una estimación.

Si usted administra una tienda Magento, estas son medidas concretas y verificables que debe tomar inmediatamente: parchear según las correcciones oficiales (aplicar APSB26-73 y otras actualizaciones de seguridad de Adobe/ Magento), revisar la tabla cms_block y cms_page en busca de scripts o bloques no autorizados y eliminar cualquier referencia a dominios sospechosos; escanear el filesystem público (pub/media y otros) por webshells, incluyendo ficheros con extensiones inusuales o imágenes que contengan código; auditar cuentas administrativas y revocar/rotar credenciales sospechosas y forzar contraseñas fuertes más 2FA para administradores; revisar logs de acceso y errores buscando peticiones a los dominios listados y revisiones de actividad inusual; y aplicar controles de acceso (IP allowlisting para la administración, WAF con reglas para Magento y protección contra inyección de contenido). También es recomendable implementar Content Security Policy (CSP) que limite scripts a dominios permitidos y revisar el uso de localStorage para detectar código inusual que re-ejecuta cargas persistentes.

Para equipos de respuesta a incidentes y proveedores de hosting, conviene tomar imágenes forenses antes de limpiar, preservar muestras del código inyectado y coordinar el bloqueo o notificación a proveedores de servicios de DNS/CDN cuando sea apropiado. La comunidad debe vigilar además la oleada de intentos de explotación de PHP2Shell (CVE-2026-109618 y CVE-2026-109619), que han mostrado intentos de descarga de etapas adicionales en honeypots; las páginas oficiales del NVD contienen descripciones técnicas públicas de esos CVE (CVE-2026-109618 y CVE-2026-109619), y se recomienda actualizar PHP cuando existan parches.

Conclusión: la campaña documentada por Sansec es técnicamente sofisticada en su evasión —fingerprinting, persistencia con localStorage y uso de TDSs— y ha mostrado movilidad entre dominios. Los operadores de tiendas Magento deben asumir la posibilidad de compromiso si no han aplicado parches, audits o controles administrativos adecuados, y actuar ahora en las áreas concretas señaladas: parcheo, búsqueda y eliminación de bloques CMS maliciosos, escaneo de webshells, refuerzo de control de acceso y monitorización continua.