StyleSmuggler instala puertas traseras zero-day en tiendas Magento completamente actualizadas

Los atacantes están explotando una vulnerabilidad sin parchear de Magento Open Source para ejecutar código de forma remota sin autenticación e instalar una puerta trasera persistente en Linux. Adobe Commerce también podría estar expuesto, aunque ese producto aún no se ha probado de forma concluyente.

La empresa neerlandesa de seguridad para comercio electrónico Sansec bautizó el fallo como StyleSmuggler y dio a conocer la campaña el 5 de septiembre de 2026, después de observar ataques que comenzaron el 4 de septiembre. Investigaciones independientes de Disrex Group confirmaron dos intrusiones exitosas y un intento de acceso.

A fecha del 6 de septiembre, Adobe no había publicado ningún aviso, identificador CVE, parche ni solución oficial. El índice de boletines de seguridad de Commerce no se había actualizado desde el 11 de agosto.

Se confirma que las versiones actuales de Magento son vulnerables

Sansec reprodujo la cadena completa de explotación sin autenticación contra instalaciones limpias de Magento Open Source:

• 2.4.7
• 2.4.8
• 2.4.9

La empresa considera que todas las versiones actuales de Magento están afectadas, incluida la 2.4.9.

La primera víctima identificada utilizaba Magento Open Source 2.4.6-p15, con las actualizaciones de seguridad de Adobe de julio y agosto de 2026 instaladas. Adobe identifica el nivel de parche de esa rama como 2.4.6-2026-aug, el más reciente disponible para la rama 2.4.6.

Disrex investigó por separado una tienda comprometida con la versión 2.4.8 y otra que ejecutaba la 2.4.7-p2. Esta última estaba ocho niveles de parche por detrás de la entonces vigente 2.4.7-p10, pero el estado de actualización no determinó el resultado: ambos sistemas fueron comprometidos.

El alcance más allá de Magento Open Source sigue sin estar claro. Sansec no ha publicado una reproducción exitosa contra Adobe Commerce ni Adobe Commerce on Cloud, y Adobe no ha confirmado qué versiones están afectadas.

La próxima actualización de seguridad programada por Adobe es el 8 de septiembre, pero se desconoce si corregirá StyleSmuggler. A fecha del 6 de septiembre, no se había informado de ninguna inclusión en la lista de vulnerabilidades explotadas conocidas de CISA ni de ningún plazo de mitigación asociado.

Un correo electrónico malicioso completa la cadena de ataque

StyleSmuggler utiliza dos fases para convertir datos escritos durante las operaciones habituales de Magento en código PHP ejecutable.

En primer lugar, el atacante inyecta PHP en un archivo que Magento puede crear o actualizar, como un archivo de informes de errores. Después activa el correo electrónico estándar de Magento “Payment Transaction Failed Reminder”, lo que hace que la plataforma procese el archivo manipulado al generar el mensaje.

El destinatario no necesita abrir el correo. El código puede ejecutarse incluso si el envío falla.

Por ello, cualquier aumento inusual de los recordatorios de pagos fallidos debería investigarse, aunque estos mensajes también pueden deberse a transacciones legítimamente rechazadas.

El análisis del código fuente realizado por Disrex indica que una directiva inyectada invoca clases de Magento asociadas al compilador de inyección de dependencias de la línea de comandos. La secuencia resultante incorpora una ruta de archivo elegida por el atacante que apunta al archivo manipulado unos instantes antes.

Los investigadores situaron el posible endpoint en tres archivos bajo:

setup/src/Magento/Setup/Module/Di/Code/

Sansec no ha confirmado esta interpretación, mientras que Disrex no ha publicado la solicitud maliciosa completa. La cadena de explotación íntegra, el dropper y el análisis del implante tampoco se han publicado.

Una vez que la ejecución de código tiene éxito, un dropper PHP prueba secuencialmente seis funciones de creación de procesos. Después descarga y ejecuta la puerta trasera.

El implante se oculta como un proceso de trabajo del kernel de Linux

El malware se ejecuta en segundo plano con el engañoso nombre de proceso:

[kworker/u:8:0]

La etiqueta imita a un hilo del kernel de Linux. Sin embargo, un proceso kworker legítimo pertenece a root y no tiene memoria residente en el espacio de usuario. Un proceso kworker entre corchetes que pertenezca a la cuenta de un sitio Magento y consuma memoria es muy sospechoso.

El implante establece su línea de comandos con el nombre entre corchetes, por lo que la detección basada únicamente en el campo comm del proceso puede no identificarlo.

La ubicación principal de la carga útil está fuera de la raíz web:

~/.local/share/.gvfsd/gvfsd-user

Disrex describió la carga útil como un ejecutable Rust despojado y enlazado estáticamente de aproximadamente 1,9 MB, con compilaciones para x86-64 y arm64. La persistencia se establece mediante una entrada de cron que lo reinicia cada cinco minutos:

*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user

Una segunda variante ejecuta una carga útil desde /tmp/.kw_.

En lugar de sustituir el crontab mediante el comando habitual, el malware escribe directamente en:

/var/spool/cron/crontabs/

Esta técnica evita generar en los registros del sistema el evento esperado de sustitución del crontab. Una de las tiendas comprometidas contenía la misma línea maliciosa 1.728 veces, y el implante la restauraba un segundo después de eliminarla.

Otras rutas relevantes son:

~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
/tmp/.gvfsd_<8hex>.lock
/tmp/.kw_<random><random>

En un sistema, el ejecutable en ejecución era distinto de la carga útil almacenada en disco. Por ello, los equipos de respuesta deberían calcular el hash tanto del archivo como del ejecutable asignado a través de:

/proc/<pid>/exe

Dos tiendas fueron comprometidas antes de que llegaran las defensas

Disrex, que gestiona servicios de alojamiento Magento bajo la marca RexHosting, confirmó dos compromisos en cuentas de clientes aisladas.

La primera tienda afectada ejecutaba Magento Open Source 2.4.8 y fue atacada a las 23:10 UTC del 4 de septiembre. Sansec Shield estaba instalado, habilitado y bloqueaba el resto del tráfico malicioso, pero todavía no había reglas específicas para StyleSmuggler.

Una segunda tienda con 2.4.7-p2 fue atacada por primera vez a las 00:55 UTC del 5 de septiembre. No era cliente de Shield. Disrex utilizó las pruebas recuperadas de este sistema para elaborar su análisis técnico y las reglas para el servidor web.

Ambos compromisos se produjeron durante un intervalo aproximado de ocho horas entre la primera actividad observada de la campaña y la disponibilidad de protecciones específicas.

Las cuentas afectadas tenían un único propietario del sitio cada una, no disponían de acceso sudo y no ofrecían ninguna vía hacia los entornos de otros clientes. El proceso malicioso se ejecutaba con la cuenta sin privilegios del sitio. Disrex no encontró movimientos laterales ni compromisos de otros sitios alojados.

Ambas tiendas fueron contenidas el mismo día en que se descubrieron, aproximadamente once y catorce horas después del primer contacto, respectivamente. Las sesiones se invalidaron y se inició la rotación de credenciales como medida preventiva.

Los investigadores no encontraron pruebas de:

• Datos robados
• Skimmers de tarjetas de pago
• Cuentas de administrador fraudulentas
• Puertas traseras en la base de datos
• Movimientos laterales
• Compromiso de sitios vecinos

Se desconoce el número de tiendas afectadas fuera de estas investigaciones.

La detección debe ir más allá de la raíz de documentos

La comprobación de detección inicial de Sansec busca en var/report/:

X_TRACE_

Esta búsqueda por sí sola es insuficiente. En cambio, las dos infecciones examinadas por Disrex manipularon:

var/log/system.log

El marcador también cambió durante la campaña. Las primeras solicitudes utilizaban una cabecera con el formato X-TRACE- seguida de diez caracteres hexadecimales; en el tráfico posterior se omitía la palabra TRACE. Las reglas de detección deberían identificar la estructura general en lugar de una cadena fija.

Un TypeError que indique que array_merge() ha recibido un entero inmediatamente después de la operación de inclusión correspondiente señala una explotación exitosa. No es un comportamiento universal: una variante más silenciosa devuelve una matriz vacía y no deja un error equivalente.

Los indicadores SHA-256 publicados son:

e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220

Los indicadores de red son:

247.cdnflare[.]xyz
99.84.67[.]186:443
88.216.72[.]181
5.181.86[.]133

La ausencia de tráfico externo no demuestra que un sistema esté limpio. Un implante no realizó ninguna conexión saliente observable, pero abrió 28 conexiones con el servicio Redis de la tienda en el puerto 6379 y accedió a los datos de sesión de Magento.

Los análisis limitados a la raíz de documentos también pueden generar una falsa sensación de seguridad. En una tienda comprometida, el análisis devolvió un resultado limpio, aunque el directorio personal contenía la carga útil y 1.728 entradas de cron maliciosas.

Qué deben hacer ahora los operadores de Magento

Ante la ausencia de un parche oficial, los operadores deben combinar la reducción temporal de la exposición con comprobaciones forenses a nivel de cuenta.

Sansec recomienda deshabilitar temporalmente GraphQL en las tiendas que no estén protegidas por Shield. Esto puede resultar inviable en las tiendas headless y en las basadas en aplicaciones web progresivas, que dependen de GraphQL, mientras que las implementaciones clásicas y Hyvä generalmente no lo necesitan.

Disrex, ProxiBlue y Graycore han publicado mitigaciones no oficiales. El parche de código fuente de Disrex impide que tres métodos del escáner de inyección de dependencias se ejecuten a través de HTTP y los limita a la ejecución desde la línea de comandos. Según los informes, su versión para composer-patches se aplica a Magento 2.4.6 a 2.4.9 y se mantiene tras las implementaciones de Composer.

Los administradores deberían probar primero la compatibilidad. El paquete de terceros mageplaza/module-admin-permissions invoca ClassesScanner.php mediante HTTP, por lo que la protección puede dejar inutilizada su interfaz administrativa.

Las reglas publicadas para nginx y Apache bloquean los parámetros utilizados en los ataques observados, pero solo cuando aparecen en la cadena de consulta. Los parámetros equivalentes incluidos en cuerpos POST o JSON todavía llegan a PHP. Estas reglas interrumpen la campaña actual, pero no corrigen la vulnerabilidad.

Los equipos de respuesta a incidentes deberían buscar en toda la cuenta de alojamiento, incluidos los directorios personales de los usuarios, /tmp, los archivos de la cola de cron, var/report/ y var/log/system.log. También deberían inspeccionar los procesos en ejecución a través de /proc, comparar los hashes de la memoria y del disco, invalidar las sesiones de Magento y rotar las credenciales.

Un análisis limpio de la tienda no es suficiente. Tampoco lo es eliminar el binario visible sin terminar el proceso y eliminar su persistencia en cron.