Una vulnerabilidad de día cero recién descubierta en Magento Open Source y Adobe Commerce está siendo explotada activamente por atacantes para tomar el control total de tiendas en línea, y todavía no hay un parche oficial disponible.

La firma holandesa de seguridad de comercio electrónico Sansec reveló el fallo, apodado StyleSmuggler, el 5 de septiembre de 2026, advirtiendo que atacantes no autenticados pueden lograr la ejecución remota de código en instalaciones vulnerables y que los ataques reales comenzaron el día anterior.

La empresa afirmó que publicaba sus hallazgos prematuramente, antes de completar su análisis técnico completo, "porque hay tiendas siendo comprometidas en este preciso momento".

StyleSmuggler afecta a todas las versiones actuales de Magento y Adobe Commerce, incluida la última versión 2.4.9, y no requiere ningún tipo de autenticación para ser explotada.

Sansec reprodujo la cadena de ataque completa sin autenticación en instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9, confirmando que el error no está vinculado a una sola versión obsoleta.

Lo más inquietante es que la primera víctima identificada utilizaba la versión 2.4.6-p15 con los parches de seguridad de julio y agosto de 2026 totalmente aplicados, lo que significa que las tiendas totalmente parcheadas fueron comprometidas con la misma facilidad que las descuidadas.

Hasta el 6 de septiembre, Adobe no ha emitido ningún aviso, no ha asignado un identificador CVE ni ha publicado ninguna solución oficial o alternativa, y el boletín de seguridad de Commerce más reciente de la empresa data todavía del 11 de agosto.

El exploit se desarrolla en dos etapas distintas que abusan del propio renderizado de plantillas y los sistemas de correo electrónico de Magento, en lugar de un único punto de inyección obvio. En la primera etapa, los atacantes plantan código PHP malicioso dentro de un archivo que el propio Magento escribe durante su funcionamiento normal, como un informe de fallo de pago, manipulando las propiedades de "estilos" dentro de una solicitud GraphQL para evadir la sanitización de entrada existente.

RCE de día cero en Magento y Adobe Commerce

Un análisis independiente de la firma de hosting de Magento Disrex Group, que gestionó dos tiendas vulneradas, encontró que una directiva manipulada dentro del texto inyectado obliga a una cadena de clases propias de Magento a ejecutar código que solo debía ejecutarse a través del compilador de inyección de dependencias de la línea de comandos, incluyendo finalmente el archivo de registro envenenado por el atacante.

La segunda etapa activa la ejecución. Sansec descubrió que StyleSmuggler provoca deliberadamente que Magento envíe su correo estándar de "Recordatorio de fallo en la transacción de pago", y el código envenenado se ejecuta en el momento en que Magento renderiza ese mensaje internamente, lo que significa que nadie tiene que abrir ni siquiera recibir el correo para que el ataque tenga éxito.

Una vez activado, un "dropper" de PHP recorre seis funciones PHP diferentes hasta encontrar una capaz de generar un proceso, para luego descargar y lanzar un implante persistente. Disrex describió el malware como un binario de Rust pequeño y vinculado estáticamente de aproximadamente 1,9 megabytes, compilado tanto para arquitecturas x86-64 como ARM64, disfrazado como un hilo del kernel de Linux llamado "[kworker/u:8:0]" y reiniciado cada cinco minutos a través de una entrada de cron escrita directamente en el archivo de spool de crontab para evitar dejar registros normales en el sistema.

Detectar una infección es más difícil de lo que parece porque el malware evade activamente las comprobaciones simples. Un hilo de trabajo real del kernel de Linux pertenece a root y no consume memoria residente, por lo que cualquier proceso "[kworker]" entre corchetes que se ejecute bajo la cuenta de usuario del propio sitio web con uso real de memoria es una señal de alerta.

Disrex también descubrió que el binario que se ejecuta en memoria a veces difiere del archivo que está en el disco, lo que significa que, para ser meticulosos, debes calcular el hash tanto del archivo como del proceso en vivo.

En una tienda comprometida, el implante no realizó ninguna conexión saliente a internet; en su lugar, abrió 28 conexiones simultáneas a la instancia de Redis del propio sitio para leer datos de sesión de Magento en vivo, lo que le permitió operar casi invisiblemente para el monitoreo basado en red.

La propia guía de detección de Sansec busca una cadena de marcador en el directorio var/report de Magento, pero Disrex encontró que sus dos tiendas vulneradas fueron en realidad envenenadas a través de var/log/system.log, lo que significa que debes revisar ambas ubicaciones.

Con el próximo lanzamiento de seguridad de Adobe programado para el 8 de septiembre y sin confirmación de que abordará este fallo, los propietarios de tiendas quedan dependiendo de medidas provisionales. Sansec recomienda desactivar temporalmente GraphQL por completo para las tiendas que no dependan de escaparates "headless" o aplicaciones web progresivas, ya que los temas clásicos y Hyvä generalmente no lo necesitan.

Disrex, el investigador de seguridad ProxiBlue y el proveedor Graycore han publicado independientemente parches de código no oficiales que protegen clases específicas de Magento y funciones de plantillas de correo electrónico, aunque los tres subrayan que estas son medidas de endurecimiento y no una solución real, y Disrex advierte específicamente que sus reglas solo bloquean el patrón actual de tráfico de ataque, no la vulnerabilidad subyacente.

Las protecciones a nivel de servidor que no dependen en absoluto de comprender la cadena del exploit, como desactivar la función proc_open de PHP y montar directorios temporales con noexec, también han demostrado ser efectivas para evitar que el dropper lance su carga útil.