StyleSmuggler y los últimos ataques a tiendas Magento: cómo actúan los hackers y cómo reducir el riesgo

Los últimos días han puesto de manifiesto algo que los administradores de tiendas online saben desde hace tiempo, pero que resulta fácil pasar por alto en el mantenimiento diario: un sistema actualizado no siempre significa un sistema seguro. Cuando aparece una vulnerabilidad de tipo 0-day, los atacantes no esperan a un comunicado oficial del fabricante, a un número CVE ordenado ni a una fecha cómoda para implementar el parche. Los bots escanean internet, buscan endpoints vulnerables e intentan instalar un acceso persistente más rápido de lo que la mayoría de las empresas tarda en convocar una reunión.

Así es precisamente el caso de StyleSmuggler, una vulnerabilidad explotada activamente y notificada por Sansec el 5 de septiembre de 2026. Según Sansec, los ataques comenzaron el 4 de septiembre y afectan a Magento Open Source y Adobe Commerce. La información más importante para los propietarios de tiendas es contundente: la vulnerabilidad también se observó en instalaciones consideradas completamente actualizadas.

Este texto no es una guía de ataque. Es un resumen práctico de cómo es hoy una intrusión en una tienda e-commerce y qué se puede hacer aquí y ahora, antes de que aparezca o se confirme un parche oficial del fabricante.

¿Qué ha ocurrido?

StyleSmuggler se describe como un RCE no autorizado, es decir, la posibilidad de ejecutar código en el servidor sin iniciar sesión en el panel de administración. En términos sencillos: el atacante no necesita la contraseña del administrador, una cuenta de empleado comprometida ni acceso SSH. Basta con una aplicación vulnerable expuesta a internet.

Según los análisis públicos, el ataque consta de varias fases:

1. El atacante envía una solicitud manipulada a Magento aprovechando el endpoint GraphQL.
2. El código malicioso llega a un lugar que Magento procesa posteriormente por sí mismo.
3. La aplicación ejecuta el código durante el mecanismo estándar de gestión de correos electrónicos, entre otros, en el escenario de error de pago.
4. En el servidor se instala un backdoor, es decir, un mecanismo persistente de retorno.

Es un modelo especialmente peligroso porque no requiere que un empleado haga clic en un enlace ni que se produzca un intento de inicio de sesión correcto. La tienda puede ser atacada únicamente por estar disponible públicamente.

¿Cómo actúan hoy los hackers?

Las intrusiones en tiendas online cada vez se parecen menos al hackeo manual de un único objetivo. Con más frecuencia se asemejan a una campaña automatizada:

• escaneo de internet en busca de un endpoint concreto,
• envío de intentos preparados para explotar la vulnerabilidad,
• instalación de un proceso que se hace pasar por un elemento legítimo del sistema,
• mantenimiento del acceso mediante cron u otro mecanismo de autoarranque,
• recopilación de sesiones, secretos, claves API o datos de pago,
• posible instalación adicional de un webshell, un skimmer u otro backdoor.

En el caso de StyleSmuggler hay dos detalles especialmente relevantes. En primer lugar, el backdoor puede encontrarse fuera del directorio de la tienda, por lo que una simple revisión de los archivos de Magento no es suficiente. En segundo lugar, el proceso puede hacerse pasar por un elemento del sistema, por ejemplo con un nombre parecido a kworker, fc-cache o chronyd. Para un ojo poco entrenado puede parecer inocente, pero si se ejecuta bajo el usuario web debería encender todas las alarmas.

¿Por qué el patch level por sí solo no basta?

Ante una vulnerabilidad habitual, la respuesta es sencilla: comprobamos la versión, actualizamos y cerramos el asunto. Con un 0-day la situación es distinta. Durante un tiempo, la vulnerabilidad se explota antes de que el fabricante publique el parche o antes de que el parche se relacione de forma inequívoca con un ataque concreto.

Por eso, después de un incidente así, hay que separar dos preguntas:

• ¿la tienda sigue siendo vulnerable?
• ¿la tienda ya fue comprometida anteriormente?

No es lo mismo. Un WAF, el bloqueo de GraphQL o un parche posterior pueden limitar nuevos intentos, pero no eliminan automáticamente un backdoor que pudo haberse instalado antes.

¿Qué hacer de inmediato?

1. Limita o desactiva temporalmente GraphQL

Si la tienda no utiliza GraphQL, la decisión más sencilla es bloquear temporalmente /graphql hasta que exista un parche confirmado. Muchas tiendas Magento clásicas, incluidas bastantes implementaciones basadas en Hyvä, no necesitan GraphQL público para que funcione el front. Es distinto en tiendas headless y PWA: ahí el bloqueo puede detener las ventas, por lo que hay que aplicar reglas WAF más precisas o restricciones de tráfico.

Ejemplo de orientación para nginx:

map $uri $gql_block { default 0; ~*^/+(index\.php/+)?graphql(\.php)?(/|$) 1;}

En cada vhost de Magento, antes del resto de location:

if ($gql_block) { return 403;}

Después de cambiar la configuración:

nginx -t && systemctl reload nginx

Si Varnish funciona delante de la tienda, conviene limpiar también la caché:

varnishadm ban 'req.url ~ .'

Tras la implementación hay que comprobar distintas variantes de la ruta, no solo el /graphql ideal. La prueba debe incluir, entre otros, /graphql, /GraphQL, /graphql/, /graphql.php, /index.php/graphql y variantes con dobles barras. El resultado esperado para GraphQL es 403, y para la página principal de la tienda una respuesta normal, por ejemplo 200.

2. Bloquea el vector conocido styles[...]

Si no puedes desactivar todo GraphQL, aplica al menos reglas que bloqueen el parámetro observado styles[...] en el query string y los patrones conocidos posteriores a la explotación.

Para nginx se pueden usar reglas en esta línea:

if ($query_string ~* 'styles(\[|%5[bB])') { return 403;}if ($request_uri ~* '/paypal/transparent/response/.*(eval|base64_decode|%3[cC]%3[fF])') { return 403;}if ($request_uri ~* '%3[cC]%3[fF]|<\?') { return 403;}

Para Apache, un mecanismo equivalente puede basarse en mod_rewrite, bloqueando apariciones sin codificar y codificadas de styles[, así como intentos de introducir una etiqueta PHP en la URL.

Advertencia importante: estas reglas ven la URL y el query string. Si una variante del ataque traslada el payload completo al body de la solicitud POST, una regla del servidor web por sí sola puede no ser suficiente. En ese caso se necesita un WAF que analice el body, ModSecurity, una solución tipo Sansec Shield o la desactivación temporal de GraphQL.

3. Comprueba si la tienda ya ha sido comprometida

Bloquear nuevos intentos es solo la mitad del trabajo. La otra mitad es comprobar si el ataque ya ha dejado rastros.

Ejecuta la revisión como usuario de sistema de Magento:

crontab -l | grep -i gvfsdls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache 2>/dev/nullps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'grep -ril 'x_trace_' var/report/

Presta especial atención a:

• archivos en ~/.local/share/.gvfsd/,
• archivos fc-cache en ubicaciones inusuales,
• directorios temporales del tipo /tmp/.kw_*, /tmp/.cache_*, /tmp/.fc-*,
• entradas de cron ejecutadas cada pocos minutos,
• procesos que se hacen pasar por procesos del sistema, pero que se ejecutan como usuario de la tienda,
• archivos PHP en pub/media, donde normalmente no deberían existir.

Ejemplo de comprobación rápida de webshells:

find pub/media -name '*.php' -print

Si el resultado no está vacío, hay que tratarlo como un incidente, no como una anomalía menor.

4. Revisa los logs de acceso

En los logs busca intentos dirigidos a GraphQL y solicitudes inusuales a rutas de pago. La mera presencia de una solicitud sospechosa no siempre significa una intrusión efectiva, pero demuestra que la tienda fue un objetivo.

En la práctica conviene comprobar:

• solicitudes POST a /graphql con parámetros inusuales,
• apariciones de styles[ y de su versión codificada styles%5B,
• solicitudes a /paypal/transparent/response/ con fragmentos sospechosos,
• series repentinas de solicitudes desde muchas direcciones IP,
• tráfico desde direcciones conocidas por IOC públicos.

En los materiales de trabajo aparecen, entre otros, estos IOC: 185.157.160.251, 99.84.67.186, windwsecurity.run, ntp.timesync.to. Sin embargo, no se debe limitar la defensa únicamente a estos valores. Según las descripciones de los incidentes, parte del tráfico procedía de un conjunto más amplio de direcciones e infraestructura intermediaria.

5. Primero preserva las pruebas, después limpia

Es un error frecuente: el administrador ve un proceso sospechoso, lo mata, elimina archivos y solo después empieza el análisis. Con un backdoor bien escrito, esto puede destruir los rastros más importantes e incluso dificultar la recuperación de la muestra.

El orden debería ser más conservador:

1. Preserva los logs de nginx/Apache, PHP-FPM, del sistema, de Magento y de cron.
2. Guarda la lista de procesos, archivos abiertos y conexiones de red.
3. Haz una copia de los archivos sospechosos para analizarlos.
4. Elimina las entradas de cron responsables de recrear el proceso.
5. Solo después detén los procesos y elimina los mecanismos de persistencia.
6. Fuerza el cierre de sesión de usuarios y administradores.
7. Rota los secretos: crypt/key, contraseñas de administradores, claves API de pagos, integraciones, SMTP, ERP, PIM y marketplace.

Si la tienda procesa pagos o datos de clientes, tras una compromiso confirmado hay que tratar el caso como un incidente de seguridad completo, no como una simple eliminación de virus.

Algunas reglas que reducen realmente el riesgo

Minimiza la superficie pública de ataque

Los endpoints que la tienda no utiliza no deberían estar disponibles públicamente. Esto afecta a GraphQL, paneles de administración, entornos staging, dominios demo antiguos y copias olvidadas de la tienda. En e-commerce, muy a menudo no cae producción, sino un staging antiguo con una base de datos real y los mismos secretos.

Separa entornos y permisos

El proceso de Magento no debería tener más acceso del que necesita. Sin sudo, una cuenta de sistema separada para cada tienda, separación de Redis, bases de datos independientes y comunicación saliente limitada pueden convertir una compromiso de la tienda en un incidente acotado en lugar de una catástrofe para toda la infraestructura.

Monitoriza procesos, cron y archivos fuera del webroot

Escanear únicamente el directorio de Magento no basta. El backdoor puede residir en el directorio home del usuario, en /tmp, en la caché de fuentes o en otro lugar accesible para el proceso de la aplicación. La monitorización debería incluir:

• nuevas entradas de cron,
• procesos inusuales bajo el usuario web,
• nuevos archivos ejecutables en directorios temporales,
• conexiones a Redis, bases de datos e internet,
• cambios en app/etc/env.php,
• nuevas cuentas de administradores.

Actualiza, pero no confundas actualización con análisis del incidente

Cuando Adobe publica un parche, hay que implementarlo. Pero después de un ataque 0-day, la simple aplicación del parche no responde a la pregunta de si alguien ya estaba dentro. Por eso, tras aplicar el parche, sigue siendo necesario revisar IOC, logs, sesiones y secretos.

Prepara reglas de emergencia listas para usar

Conviene tener en el repositorio o en la documentación operativa fragmentos preparados para nginx, Apache, Varnish y WAF. En una crisis no hay tiempo para escribir reglas desde cero. También es una buena práctica probar los bloqueos en staging antes de necesitarlos en producción.

¿Qué debería hacer hoy el propietario de una tienda?

Si gestionas Magento o Adobe Commerce, haz como mínimo lo siguiente:

1. Haz una lista de todas las instancias: producción, staging, demo y copias de trabajo.
2. Comprueba dónde GraphQL es público y si realmente es necesario.
3. Implementa un bloqueo temporal de GraphQL o reglas que bloqueen styles[...].
4. Verifica el bloqueo con pruebas HTTP.
5. Busca en el servidor procesos, cron, archivos y logs que apunten a StyleSmuggler.
6. Si encuentras IOC, preserva las pruebas y trata el caso como un incidente.
7. Tras el parche oficial del fabricante, actualiza cada instancia, también staging y copias antiguas.
8. Después de actualizar, realiza una nueva revisión y rota los secretos si la tienda pudo haber sido comprometida.

La peor decisión es esperar a que el asunto se aclare. Con un 0-day explotado activamente, el tiempo juega a favor del atacante. Incluso un bloqueo temporal, si está bien probado e implementado de forma consciente, puede comprar horas valiosas.

Resumen

StyleSmuggler es un buen ejemplo del riesgo moderno en e-commerce: el ataque no empieza en el panel de administración, sino en un endpoint público; no termina en un único archivo dentro del directorio de la tienda, sino en un proceso persistente fuera del webroot; y un patch level actualizado no responde automáticamente a si la tienda estuvo segura durante la ventana de ataque.

La defensa debe ser igual de práctica: reducir la superficie, bloquear el vector conocido, comprobar la compromiso, preservar las pruebas, rotar secretos y solo entonces considerar el asunto bajo control.

En estas situaciones no gana quien tiene la política de seguridad más bonita, sino quien cuenta con procedimientos preparados, logs, separación de entornos y capacidad para implementar rápidamente reglas de emergencia sin detener todo el negocio.

Fuentes y materiales

• Sansec: https://sansec.io/research/stylesmuggler-0day
• The Hacker News: https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
• Adobe Security Bulletin para Adobe Commerce: https://helpx.adobe.com/security/products/magento/apsb26-138.html