La empresa neerlandesa Sansec informa sobre una campaña a gran escala en la que los atacantes han infectado 953 tiendas online, en su mayoría basadas en la plataforma Magento (Adobe Commerce). La campaña está activa desde julio de 2025 y utiliza el mecanismo de bloques CMS de Magento para inyectar un loader de JavaScript malicioso que evita deliberadamente los escáneres de seguridad automatizados y solo entrega el código malicioso a compradores reales. Los propietarios de tiendas en Adobe Commerce y Magento Open Source deben comprobar de inmediato las tablas cms_block y cms_page en busca de código sospechoso y aplicar los parches de seguridad más recientes.
Mecanismo de ataque: los bloques CMS como vector de persistencia
Los atacantes inyectan un pequeño fragmento de código en los bloques CMS de Magento, es decir, en la tabla cms_block de la base de datos, que se utiliza para renderizar contenido estático (cabecera, pie de página, banners promocionales) en las páginas de la tienda. Cuando un comprador visita una página infectada, el navegador se conecta al servidor de los atacantes, que primero comprueba si el visitante es una persona real o un escáner automatizado. Los escáneres no reciben nada, lo que explica en gran medida por qué la campaña permaneció sin detectarse durante tanto tiempo.
Según Sansec, durante la campaña se han utilizado cinco dominios:
manulfie[.]click— desde julio de 2025neswnsssn[.]click— desde diciembre de 2025lanhd6549tdhse[.]top— desde marzo de 2026additionalver[.]com— desde junio de 2026deepveindrilling[.]com— desde octubre de 2026
Según Sansec, el último dominio, registrado el 6 de octubre de 2026, se ha detectado en bloques CMS de 83 tiendas.
Dos versiones del loader y evasión de la protección
Los investigadores identificaron dos versiones del loader. La primera almacena el payload en el localStorage del navegador, lo que garantiza la ejecución repetida del código malicioso en visitas posteriores, incluso si el dominio externo de los atacantes deja de estar disponible. La segunda versión, además, utiliza fingerprinting del navegador para filtrar bots y escáneres de seguridad.
Las primeras iteraciones de la campaña utilizaron la plataforma Keitaro como sistema de distribución de tráfico (TDS), lo que permitía devolver distintas respuestas según las características del visitante. El dominio más reciente, deepveindrilling[.]com, dejó de usar Keitaro e integró la lógica de filtrado de bots directamente en el loader.
En el momento de la publicación del estudio de Sansec, el payload final entregado por el loader no había sido capturado. Esto significa que la naturaleza exacta de la amenaza para los compradores —ya sea robo de datos de pago, redirecciones u otra actividad maliciosa— sigue sin estar determinada.
Vectores de acceso inicial y discrepancias en la evaluación de la explotación
Según la estimación de Sansec, 471 tiendas fueron comprometidas a través de la vulnerabilidad CVE-2026-48356 (PolyShell), una vulnerabilidad crítica de carga de archivos de tipo peligroso (CWE-434) en Adobe Commerce, con una puntuación CVSS de 9.6 según los datos de Adobe. Otras 102 tiendas, según Sansec, fueron comprometidas mediante PolyShell o CVE-2025-54236 (SessionReaper), una vulnerabilidad de validación incorrecta de entrada con una puntuación CVSS de 9.1.
Aquí existe una discrepancia importante: Adobe afirma en el boletín APSB26-73 que la empresa no tenía constancia de la explotación en ataques reales de las vulnerabilidades cubiertas por esta actualización, mientras que Sansec vincula directamente CVE-2026-48356 con la infección masiva. Para CVE-2025-54236 la situación es diferente: Adobe confirma el hecho de la explotación en la naturaleza. Ambas vulnerabilidades se han incluido en el catálogo CISA KEV.
Versiones afectadas de Adobe Commerce para CVE-2026-48356: 2.4.9, 2.4.8-p5 y anteriores, 2.4.7-p10 y anteriores, 2.4.6-p15 y anteriores, 2.4.5-p17 y anteriores, 2.4.4-p18 y anteriores.
Los parches no garantizan la seguridad
Una de las conclusiones más preocupantes del estudio de Sansec es que una tienda en Magento 2.4.7-p10 completamente parcheada, sin actualizaciones de núcleo pendientes, fue comprometida mediante la creación de una cuenta de administrador falsa que luego se utilizó para inyectar código malicioso. Esto significa que actualizar a la última versión es una condición necesaria, pero no suficiente, para la protección. El loader se almacena en una tabla de la base de datos y no en el sistema de archivos, por lo que eliminar el script de los archivos no solucionará la infección si no se comprueba la base de datos y no se revocan las cuentas comprometidas.
Relación con PHP2Shell
La publicación de Sansec coincidió en el tiempo con la explotación activa de dos vulnerabilidades críticas de RCE en PHP —CVE-2026-109618 y CVE-2026-109619 (CVSS 9.2 cada una)— conocidas como PHP2Shell. Según el informe del investigador Adel Karimi, el 24 de octubre de 2026 se registraron 35 casos de ejecución de comandos shell en honeypots con PHP 8.4.26 bajo Apache mod_php. Ambas vulnerabilidades se han incluido en el catálogo CISA KEV. Ya hemos escrito sobre estas vulnerabilidades: afectan a versiones de PHP anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Es importante subrayar que se trata de un vector de amenaza distinto de la campaña con bloques CMS de Magento: PHP2Shell está relacionado con vulnerabilidades del propio intérprete de PHP, mientras que la campaña de Magento explota vulnerabilidades a nivel de aplicación.
Indicadores de compromiso
Dominios de los loaders:
manulfie[.]click,neswnsssn[.]click,lanhd6549tdhse[.]topadditionalver[.]com,deepveindrilling[.]comhdfdsi84j3h[.]top,c85grt98sd[.]com
Direcciones IP: 15.204.59.70, 104.28.208.84, 144.48.4.242, 162.35.99.94
Recomendaciones
- Compruebe la base de datos: busque en las tablas
cms_blockycms_pagelos patronesfpCode,se_referrer,localStorage.getItemy los dominios enumerados. - Audite las cuentas: revise la lista de administradores en busca de cuentas desconocidas o sospechosas, incluso en sistemas completamente actualizados.
- Aplicar los parches: instale la actualización APSB26-73 para corregir CVE-2026-48356 y asegúrese de que el parche para CVE-2025-54236 se haya aplicado previamente.
- Actualice PHP: a las versiones 8.2.35, 8.3.36, 8.4.27 o 8.5.12 para cerrar las vulnerabilidades PHP2Shell.
- Refuerce la autenticación: implemente contraseñas robustas y autenticación de dos factores para los paneles administrativos.
La campaña demuestra la evolución de las tácticas de web skimming: almacenar el loader en la base de datos de la CMS en lugar del sistema de archivos, la persistencia mediante el localStorage del navegador y el filtrado activo de escáneres hacen que la detección mediante herramientas estándar sea extremadamente difícil. Los propietarios de tiendas en Adobe Commerce y Magento deben auditar de inmediato las tablas cms_block de la base de datos y las cuentas administrativas: la simple actualización a la última versión de la plataforma no basta para garantizar la ausencia de compromiso.
