El zero-day StyleSmuggler permite a los atacantes controlar remotamente tiendas Magento parcheadas

Una vulnerabilidad hasta ahora desconocida, bautizada como StyleSmuggler, está siendo explotada activamente contra tiendas Magento y Adobe Commerce, incluidos sistemas con las actualizaciones de seguridad más recientes.

El ataque permite ejecutar código de forma remota y sin autenticación mediante el procesamiento de plantillas de Magento y el manejo relacionado con GraphQL. Las intrusiones exitosas han instalado una puerta trasera para Linux basada en Rust y, en algunos casos, un web shell PHP oculto.

SecurityAffairs hizo pública la campaña el 7 de septiembre de 2026 y atribuyó la investigación técnica a Sansec. Los primeros casos de explotación se observaron el 4 de septiembre.

No se ha divulgado ningún identificador CVE, puntuación CVSS ni clasificación oficial de gravedad de Adobe. Tampoco se conoce el estado de la vulnerabilidad en el catálogo de vulnerabilidades explotadas conocidas de la Cybersecurity and Infrastructure Security Agency de Estados Unidos.

Las tiendas actuales y completamente parcheadas siguen expuestas

StyleSmuggler afecta a Magento Open Source y Adobe Commerce, pero todavía no existe una matriz de versiones oficial y autorizada.

Sansec reprodujo el exploit en instalaciones limpias e identificó como víctima inicial un sistema con Magento 2.4.6-p15 y las actualizaciones de seguridad de julio y agosto de 2026 instaladas. Entre las versiones actuales de Magento Open Source identificadas específicamente como afectadas se incluyen:

• Magento Open Source 2.4.7
• Magento Open Source 2.4.8
• Magento Open Source 2.4.9

Otra fuente afirma que todas las versiones de Magento y Adobe Commerce son vulnerables. Hasta que Adobe publique un aviso, los administradores no deben dar por segura ninguna versión, ya sea antigua, reciente o completamente parcheada.

La exposición es considerable. Según los informes, Magento funciona en más de 160.000 sitios web, incluidos aproximadamente 14.000 de los principales millón de sitios. Un compromiso del servidor puede poner al alcance del atacante registros de clientes, credenciales administrativas, tokens de API, secretos de proveedores de pago, contraseñas de bases de datos y claves de acceso a la nube.

Según los informes, Adobe estaba preparando una corrección. Se esperaba una actualización de seguridad programada para el 8 de septiembre, pero no se sabía si incluiría la solución para StyleSmuggler.

Una notificación de pago fallido se convierte en el desencadenante de la ejecución

El exploit ataca la cadena de procesamiento de plantillas de Magento. Inyecta PHP mediante el procesamiento asociado a la propiedad styles y GraphQL, eludiendo los controles destinados a rechazar contenido peligroso en las plantillas.

La cadena observada consta de dos pasos principales. Primero, un atacante no autenticado crea o manipula un registro de Magento que contiene PHP malicioso. Una de las vías demostradas consiste en generar un informe de pago fallido.

Posteriormente, Magento procesa su notificación estándar Payment Transaction Failed Reminder. Durante esa operación, la plataforma evalúa el contenido manipulado y ejecuta el PHP incrustado en el servidor.

No es necesario que ningún cliente o administrador abra un archivo adjunto ni siga un enlace. El exploit puede tener éxito aunque el correo de notificación nunca llegue a entregarse, porque la ejecución se produce durante el procesamiento de las plantillas en el servidor de Magento.

Por tanto, un aumento inexplicable de los recordatorios de pagos fallidos puede indicar una explotación. No constituye una prueba definitiva, ya que los fallos de pago legítimos generan el mismo tipo de notificación.

Cambiar el backend de sesiones de Magento no bloquea el ataque de forma fiable. En un incidente, un intento que utilizaba el almacenamiento de sesiones falló. Ocho segundos después, el mismo operador cambió a un archivo subido mediante la funcionalidad de opciones personalizadas de Magento y consiguió ejecutar código.

Este cambio tan rápido sugiere que los atacantes están adaptando activamente sus métodos de entrega. Las defensas basadas en una única ubicación de carga o en un patrón de prueba de concepto probablemente no serán suficientes.

La puerta trasera en Rust se oculta tras nombres de procesos de Linux y tráfico NTP

Los ataques exitosos han desplegado un implante compacto para Linux basado en Rust. El malware se ejecuta en segundo plano, se conecta a una infraestructura controlada por el atacante y espera órdenes.

Cuando se publicaron los hallazgos, no se habían observado comandos posteriores enviados por el implante. Sin embargo, un host que ejecuta la puerta trasera debe considerarse comprometido, ya que el operador conserva la capacidad de ejecutar comandos de forma remota.

El malware ha cambiado la forma de hacerse pasar por otros procesos entre distintas muestras:

• Una muestra inicial aparecía como [kworker/u:8:0]
• Una variante observada el 6 de septiembre utilizaba fc-cache
• Una muestra observada el 7 de septiembre utilizaba chronyd

Estos nombres imitan a un proceso de trabajo del kernel, la utilidad de Linux para la caché de fuentes y un daemon habitual de sincronización horaria. Los nombres de los procesos por sí solos no permiten distinguir el implante de software legítimo.

La versión que utilizaba fc-cache se copiaba en ~/.cache/fontconfig/fc-cache, creaba un archivo de bloqueo PID y establecía persistencia mediante cron. Su tarea programada volvía a ejecutar el implante cada 30 minutos.

Otras compilaciones utilizaban mecanismos de persistencia diferentes. Una variante de chronyd dependía de cron, mientras que otra se reiniciaba sin dejar una entrada de cron visible. Por tanto, un crontab vacío no demuestra que el servidor esté limpio.

Las primeras muestras se comunicaban mediante TLS y WebSockets. Las versiones más recientes disfrazan el tráfico de comando y control como actividad del Network Time Protocol mediante el envío de paquetes UDP al puerto 123.

El implante resuelve ntp.timesync.to cada 60 segundos y transmite paquetes de 48 bytes que imitan respuestas de servidores NTP. Solo los primeros cuatro bytes siguen una estructura convencional similar a NTP. El resto de los datos puede contener el identificador del implante, el nombre del host, el nombre de usuario, la versión del sistema operativo, el tiempo de actividad, el uso de memoria y disco, el estado de root y la versión del malware.

Los dominios observados estaban asociados a 185.157.160.251 el 7 de septiembre. La puerta trasera también puede consultar ipify, icanhazip, ident.me e ipinfo.io para determinar la dirección IP pública del servidor.

Antes de enviar señales, comprueba el valor TracerPid de Linux en busca de indicios de depuración o trazado. Si detecta trazado, el malware se instala igualmente, pero suprime las comunicaciones de red.

Un segundo actor ocultó un web shell en directorios de caché de imágenes

Los investigadores también encontraron indicios de que un operador aparentemente distinto estaba explotando tiendas comprometidas. Este actor instaló un pequeño dropper PHP que escribía un web shell en la caché de imágenes de productos de Magento.

El shell se colocaba bajo nombres de directorio similares a hashes, lo que le ayudaba a mezclarse con el contenido de caché generado. Normalmente devolvía una respuesta 404 de apariencia legítima.

La funcionalidad maliciosa solo se activaba cuando una solicitud incluía el encabezado correcto X-Cache-Token. Entonces, el shell ejecutaba el PHP recibido mediante un parámetro POST.

Antes de instalar el shell, el dropper se conectaba a:

457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site

Esa dirección pertenece a un servicio público de pruebas fuera de banda que se utiliza habitualmente para confirmar que el código inyectado se ha ejecutado. La carga recuperada se originó en un encabezado de solicitud Store de Magento, mientras que sus etiquetas PHP permanecían escapadas como JSON en el registro almacenado por Magento.

Por tanto, eliminar un proceso visible de Rust no es suficiente. Un servidor afectado también puede contener registros modificados, plantillas manipuladas, cargas subidas, persistencia mediante cron y shells PHP ocultos en ubicaciones de medios o caché con permisos de escritura.

Indicadores que los defensores deben investigar de inmediato

Los operadores de Magento deben correlacionar la telemetría de la aplicación, el host, el DNS y la red, en lugar de depender de un único indicador. Las comprobaciones prioritarias incluyen:

• Aumentos repentinos de la actividad Payment Transaction Failed Reminder
• Etiquetas PHP o etiquetas PHP escapadas como JSON inesperadas en los registros de Magento
• Plantillas modificadas, informes sospechosos y cargas inusuales mediante opciones personalizadas
• Procesos llamados [kworker/u:8:0], fc-cache o chronyd ejecutándose desde rutas anómalas
• El archivo ~/.cache/fontconfig/fc-cache
• Tareas de cron que ejecuten binarios sospechosos cada 30 minutos
• Mensajes repetidos crontab: command not allowed relacionados con cuentas como www-data
• Archivos PHP bajo pub/media, especialmente en directorios de caché de imágenes de productos
• Solicitudes que contengan el encabezado X-Cache-Token
• Solicitudes DNS para ntp.timesync.to
• Conexiones relacionadas con 185.157.160.251
• Tráfico UDP/123 saliente inesperado o paquetes similares a NTP de 48 bytes
• El dominio OAST indicado en los registros de Magento, del servidor web, DNS o proxy

Un proceso chronyd de apariencia legítima que genere nueve paquetes rápidos en modo servidor NTP cada minuto resulta especialmente sospechoso. Los administradores deben comparar ese tráfico con las fuentes horarias configuradas en el host y con su patrón normal de sincronización.

Los indicadores pueden cambiar rápidamente. La campaña ya ha modificado los nombres de los procesos, las técnicas de persistencia y las vías de explotación entre el 6 y el 7 de septiembre.

Deshabilitar GraphQL cuando sea posible y tratar las detecciones como un compromiso

Hasta que Adobe publique una corrección oficial y los administradores la apliquen, Sansec recomienda deshabilitar temporalmente GraphQL cuando sea operativo hacerlo. Esto puede interrumpir funciones de la tienda o integraciones externas, por lo que las organizaciones deben probar sus efectos y considerar controles compensatorios cuando no sea posible deshabilitar GraphQL.

Los equipos deben inspeccionar los directorios de Magento con permisos de escritura, los archivos de cola de cron, los árboles de procesos, los registros de autenticación, los registros del servidor web, el historial de DNS y el tráfico UDP/123 saliente. Cualquier indicador de StyleSmuggler debe activar el aislamiento del host y la conservación de evidencias forenses.

La respuesta al incidente también debe incluir la rotación de las contraseñas de los administradores de Magento, los tokens de API, las credenciales de bases de datos, los secretos de proveedores de pago y las claves de nube accesibles desde el servidor. Antes de restaurar el servicio, los investigadores deben buscar web shells secundarios, registros maliciosos, plantillas modificadas, ejecutables subidos y mecanismos de persistencia fuera de cron.

Tener el sistema completamente parcheado no protege contra esta campaña. Hasta que exista una corrección verificada, los sistemas expuestos de Magento y Adobe Commerce deben supervisarse como potencialmente vulnerables, y los sistemas que presenten indicadores relacionados deben tratarse como ya comprometidos.