StyleSmuggler: el zero-day de Magento que estuvo tres días sin parche

Actualización, 10 de septiembre: Adobe lo ha parcheado. Salió el 7 de septiembre como APSB26-146, con el CVE asignado como CVE-2026-75650 y puntuación 10,0. La corrección es un archivo de hotfix y no una release, y no está incluida en el parche mensual de septiembre, que salió al día siguiente: necesita los dos, el hotfix primero. Los parches de septiembre, en orden, con las descargas. Todo lo que sigue se escribió antes de que existiera la corrección y se deja tal como estaba, salvo donde se indica.

Sansec divulgó un zero-day de Magento el 5 de septiembre. Lo llaman StyleSmuggler: ejecución remota de código sin autenticación en Magento Open Source y Adobe Commerce, que termina en un backdoor corriendo en el servidor de la tienda. El primer ataque que confirmaron fue la tarde anterior, el 4 de septiembre a las 22:20 UTC. No hay CVE, ni aviso de Adobe, ni parche.

Sansec normalmente se sienta sobre un análisis hasta terminarlo. Este lo publicaron con la cadena de gadgets deliberadamente omitida, diciendo que había tiendas siendo comprometidas mientras lo escribían.

Estar al día no le libra. Sansec reprodujo el ataque en instalaciones limpias de 2.4.7, 2.4.8 y 2.4.9, y una de las víctimas estaba en 2.4.6-p15 con los parches de julio y agosto aplicados.

Qué es público, y qué no

Sansec describió la forma del ataque y se guardó los detalles que permitirían a alguien reconstruirlo:

• Llega como un POST a /graphql con un parámetro styles[...]. La propiedad styles es lo que lo cuela por las salvaguardas que normalmente detendrían una inyección de plantilla.
• La primera fase escribe PHP en un archivo que el propio Magento genera, bajo var/report o en var/log/system.log.
• La segunda fase hace que Magento incluya ese archivo, provocando a propósito el correo «Payment Transaction Failed Reminder» de la propia tienda. El código se ejecuta cuando se renderiza el correo, así que nadie tiene que abrir nada.

Disrex, trabajando en el mismo incidente, situó el punto de entrada en los scanners del compilador de inyección de dependencias de Magento: tres métodos que leen un archivo PHP desde una ruta variable y existen solo para servir a bin/magento setup:di:compile. ProxiBlue publicó la protección idéntica de forma independiente. Es una lectura comunitaria del fallo y no la de Adobe, y el desglose completo de Sansec todavía está por llegar.

Lo que aterriza después está bien documentado. Un proceso en segundo plano haciéndose pasar por [kworker/u:8:0], una entrada de crontab que lo vuelve a ejecutar cada cinco minutos, y archivos bajo ~/.local/share/.gvfsd/ y /tmp/.kw_*.

Indicadores publicados por Sansec

Compruebe antes de bloquear

Si el implante ya está en el servidor, cortar el punto de entrada con el firewall no consigue nada: se vuelve a ejecutar cada cinco minutos y no necesita la vulnerabilidad otra vez.

Así que ejecute primero las comprobaciones:

crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* 2>/dev/null
ps aux | grep -F 'kworker/u:8:0'
grep -Ral --fixed-strings '<?' var/report/ var/log/
grep -Fal 'array_merge()' var/log/system.log

Después sus logs de acceso, buscando el propio intento de entrega:

grep -F -e 'styles[' -e 'styles%5B' /var/log/nginx/access.log*

eComscan 1.9.7 tiene firmas para el implante, y Sam James sugiere ejecutarlo con --skip-dashboard --format=json --min-confidence=0 --deep. Nada de esto es concluyente. Una pasada limpia significa que las comprobaciones que ejecutó no coincidieron, y Sansec todavía no ha publicado la cadena completa.

Mitigaciones, en el orden en que las aplicaríamos

Bloquee GraphQL si puede. Es el consejo provisional del propio Sansec para quien no esté detrás de su firewall, y /graphql es la única ruta de entrega que alguien ha publicado. Que pueda permitírselo depende por completo de su tienda: un frontend PWA o headless, una app móvil y algunas extensiones de checkout y búsqueda hablan GraphQL y dejarán de funcionar. Una tienda Luma convencional normalmente no lo toca. Revise los logs de acceso antes de decidir, y haga el bloqueo en nginx o en su CDN.

Aplique la protección no oficial, con los ojos abiertos. Disrex y ProxiBlue añaden ambos una línea a tres métodos de scanner de DI:

if (PHP_SAPI !== 'cli') {
    throw new RuntimeException('Magento DI scanners are CLI-only.');
}

Esos scanners existen para servir a setup:di:compile y nunca se alcanzan legítimamente por HTTP, así que la protección elimina el punto de entrada sin cambiar cómo se comporta la tienda. Está probada contra 2.4.6 hasta 2.4.9. Las salvedades son de los propios autores: el repositorio se escribió con ayuda de IA durante un incidente en vivo, no ha pasado por revisión y no lleva garantía. Lea el parche, aplíquelo en staging y quítelo cuando Adobe publique una corrección real.

Disrex también publica reglas para el servidor web que bloquean styles[, directivas de plantilla y etiquetas PHP en las cadenas de consulta. Ellos mismos dicen que son eludibles por diseño, porque nginx y Apache no pueden ver dentro del cuerpo de un POST y el parámetro puede moverse ahí.

Refuerce el servidor. Añada proc_open a disable_functions y monte /tmp con noexec. Haga el cambio de disable_functions solo en el pool de FPM: Composer y la mayoría de las herramientas de deploy pasan por Symfony Process, que necesita proc_open, así que una prohibición global detiene sus deploys.

Un WAF cubre el hueco, no el fallo. Sansec tenía una regla de Shield publicada a las 07:15 UTC del 5 de septiembre. No tenemos ninguna relación comercial con Sansec y no recibimos nada si les compra; ejecutamos eComscan en tiendas de clientes y Shield en tiendas que seguían reinfectándose. Un firewall que bloquea una forma de petición conocida no es lo mismo que el agujero cerrado, y esa distinción importa más de lo habitual mientras la cadena completa siga sin publicarse.

Si lo encuentra

Dé por hecho que todo lo que hay en el servidor ha volado, empezando por app/etc/env.php y la clave de cifrado. Reconstruya la aplicación desde el código fuente en lugar de desinfectarla en el sitio, restaure la base de datos desde un punto en el que confíe, y después rote la clave de cifrado, las credenciales de admin, los tokens de API, las claves de integración y las credenciales de la pasarela de pago, e invalide las sesiones de los clientes.

Hemos visto tiendas limpiadas tres veces porque la limpieza se ocupó de los archivos y no de la cuenta de admin falsa, el trigger de base de datos o la entrada de cron que quedaron atrás.

8 de septiembre

Adobe tenía una publicación de seguridad programada para el 8 de septiembre antes de que empezara nada de esto, y no ha dicho si StyleSmuggler está en ella. Su boletín más reciente de Commerce sigue siendo APSB26-92, del 11 de agosto.

Si la corrección llega el lunes, llegará en la forma habitual: un parche aislado por línea de versión, que necesita la última versión -p de esa línea, con septiembre apilándose sobre agosto como agosto se apiló sobre julio. Una tienda al día lo aplica en una tarde. Una tienda con un año de retraso en versiones -p tiene una actualización que hacer primero, y esta es una mala semana para enterarse.

No esperó al día 8. Adobe publicó la corrección fuera de ciclo el lunes 7 como APSB26-146, y el boletín programado del martes, APSB26-138, salió sin ella. Los parches de septiembre, en orden.

Emyrix hace trabajo de seguridad en Magento y soporte continuo, incluida la gestión de parches y la investigación y limpieza de compromisos en tiendas que ya han sido atacadas. Si cree que StyleSmuggler ha llegado a su tienda, o quiere que alguien lo compruebe, escríbanos.

Fuentes: Sansec: StyleSmuggler — Magento and Adobe Commerce 0-day RCE under active attack · The Hacker News: Unpatched Magento and Adobe Commerce zero-day exploited to backdoor online stores · Disrex: StyleSmuggler emergency mitigation · Sam James: StyleSmuggler zero-day · Boletín de seguridad de Adobe APSB26-92