La vulnerabilidad «StyleSmuggler» permite ejecutar código sin autenticación en servidores de tiendas Magento. Los primeros ataques fueron detectados el 4 de septiembre y todavía no existe un parche oficial.
Una nueva vulnerabilidad de día cero en Magento Open Source está siendo explotada activamente contra tiendas online mientras los administradores continúan esperando una solución oficial. El fallo, bautizado como StyleSmuggler, puede permitir a un atacante ejecutar código malicioso en el servidor sin necesidad de autenticarse previamente.
La alerta adquiere especial gravedad porque los primeros ataques fueron observados el 4 de septiembre y, según la información disponible a fecha de este domingo 6, Adobe todavía no había publicado un CVE, parche oficial ni solución alternativa específica.
La empresa neerlandesa de ciberseguridad Sansec, especializada en comercio electrónico, decidió hacer pública la vulnerabilidad antes de que existiera una corrección precisamente porque, según asegura, las tiendas ya estaban siendo atacadas.
El escenario obliga a los responsables de plataformas Magento a actuar con cautela: actualizar a la última versión disponible no garantiza por sí solo estar protegido frente a este ataque concreto.
StyleSmuggler: el día cero que amenaza a Magento
Sansec asegura haber reproducido 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.
La primera víctima detectada utilizaba además Magento 2.4.6-p15 con las actualizaciones de seguridad disponibles de julio y agosto de 2026.
Es un detalle especialmente relevante. No se trata únicamente de servidores abandonados durante años sin actualizar: una tienda con las correcciones ofrecidas por el fabricante también puede encontrarse expuesta a StyleSmuggler, según las pruebas comunicadas por los investigadores.
Sansec sostiene que todas las versiones actuales estarían afectadas, incluida Magento 2.4.9.
Sin embargo, existe una diferencia importante entre lo demostrado y lo que todavía debe confirmar Adobe. Los investigadores han reproducido el ataque sobre Magento Open Source, pero no han publicado una reproducción equivalente sobre Adobe Commerce o Adobe Commerce on Cloud, y Adobe tampoco había confirmado oficialmente el alcance exacto en esos productos en la información aportada.
Los atacantes pueden instalar una puerta trasera persistente
El riesgo de StyleSmuggler va mucho más allá de provocar errores en una tienda.
Una explotación exitosa permitiría alcanzar ejecución de código en el servidor, desde donde los atacantes pueden desplegar un implante persistente.
Los indicadores publicados describen un malware que intenta camuflarse como un proceso legítimo del sistema Linux bajo el nombre [kworker/u:8:0].
El binario malicioso observado se instala fuera de la raíz web convencional, dentro del directorio personal de la cuenta que ejecuta la tienda, y utiliza una tarea cron que trata de reiniciarlo cada cinco minutos.
Esta persistencia puede dificultar considerablemente una limpieza superficial.
Disrex Group, compañía que investigó dos tiendas comprometidas, llegó a encontrar en una de ellas 1 728 entradas relacionadas con la persistencia, mientras el implante volvía a introducirlas después de ser eliminadas.
Dos tiendas comprometidas aportan pruebas independientes
La investigación adquirió mayor relevancia después de que Disrex Group documentara dos tiendas Magento Open Source comprometidas y una tercera atacada sin que la intrusión llegara a completarse.
Una de las afectadas utilizaba Magento Open Source 2.4.8. El primer ataque registrado contra ella se produjo a las 23:10 UTC del 4 de septiembre.
La segunda funcionaba con Magento 2.4.7-p2 y recibió el ataque a las 00:55 UTC del 5 de septiembre.
Las dos tiendas fueron comprometidas durante una ventana aproximada de ocho horas comprendida entre la primera explotación conocida y el despliegue de las primeras medidas defensivas descritas por los investigadores.
Según Disrex, el nivel de actualización no habría impedido este ataque, precisamente porque se trataba de una vulnerabilidad para la que todavía no existía una corrección oficial específica.
Así funciona el ataque contra Magento
La cadena descrita por los investigadores se desarrolla en varias etapas.
En términos generales, el atacante consigue primero introducir código PHP en un archivo generado por Magento. Posteriormente provoca que la propia plataforma procese ese archivo utilizando determinados mecanismos internos.
Sansec relaciona la segunda fase con el correo electrónico estándar de Magento denominado «Recordatorio de transacción de pago fallida».
Lo preocupante es que ninguna persona necesita abrir ese mensaje para que la explotación tenga éxito: el código puede ejecutarse durante el procesamiento realizado por Magento, incluso aunque finalmente falle la entrega del correo electrónico.
Disrex llegó precisamente hasta una de las infecciones después de que el propietario de una tienda recibiera un extraño correo de transacción fallida.
El mensaje contenía variables de plantilla sin resolver, una dirección de cliente perteneciente a un dominio .invalid y un importe de cero. Aquella anomalía permitió iniciar la investigación y descubrir el implante en menos de una hora.
Adobe todavía no tiene un parche oficial para StyleSmuggler
El principal problema para los administradores es que no existe todavía una solución oficial que pueda instalarse, según la información disponible en el material analizado.
A fecha de 6 de septiembre, el índice de boletines de seguridad de Adobe Commerce no reflejaba una actualización posterior a la publicada el 11 de agosto relacionada con este problema.
Sansec señala que la siguiente actualización de seguridad de Adobe está prevista para el 8 de septiembre, pero no está confirmado que incluya una corrección para StyleSmuggler.
Por tanto, cualquier parche comunitario disponible mientras tanto debe entenderse como una mitigación provisional y no como sustituto de una actualización oficial de Adobe.
Desactivar GraphQL, una medida provisional con importantes límites
Sansec ha recomendado provisionalmente desactivar GraphQL en las tiendas que puedan hacerlo hasta que exista una solución del fabricante.
La medida no resulta viable para todos.
Las tiendas headless y determinadas aplicaciones web progresivas dependen de GraphQL para funcionar, mientras que muchas instalaciones convencionales pueden prescindir temporalmente de esta funcionalidad.
También han aparecido mitigaciones desarrolladas independientemente por Disrex, ProxiBlue y Graycore, aunque ninguna debe confundirse con un parche oficial.
Algunas reglas para servidores nginx y Apache intentan bloquear las solicitudes asociadas a la campaña observada. Sin embargo, Disrex advierte de una limitación importante: pueden frenar el patrón de ataque actual sin corregir realmente la vulnerabilidad subyacente.
Qué deben vigilar ahora los administradores de Magento
Los indicadores divulgados permiten buscar posibles señales de compromiso. Entre ellos aparecen el proceso [kworker/u:8:0] ejecutándose bajo un usuario distinto de root, archivos ocultos asociados a gvfsd-user y tareas cron destinadas a recuperar el malware cada cinco minutos.
También merece atención la aparición inesperada de correos de «Recordatorio de transacción de pago fallida», especialmente cuando contienen variables sin procesar, direcciones anómalas o importes inconsistentes.
Esto no significa que cualquier correo de pago rechazado confirme un ataque: Magento genera legítimamente este tipo de notificaciones. Es una señal para investigar, no una prueba automática de infección.
Los investigadores también recomiendan revisar tanto var/report/ como var/log/system.log, ya que las infecciones observadas no siempre han dejado exactamente los mismos rastros.
No hay pruebas de un robo masivo de datos
La gravedad técnica de StyleSmuggler no debe llevar a conclusiones que las evidencias disponibles todavía no permiten sostener.
No se conoce públicamente el número total de tiendas comprometidas y tampoco se ha identificado a los responsables de la campaña.
En las dos tiendas analizadas por Disrex no se encontraron evidencias de exfiltración de datos, cuentas fraudulentas de administrador, skimmers destinados al robo de tarjetas ni movimiento lateral hacia otros clientes.
Ambas fueron neutralizadas el mismo día. Aun así, sus responsables invalidaron las sesiones y comenzaron una rotación preventiva de credenciales.
El hecho de que no se detectara robo de información en esos dos casos no permite concluir que todas las víctimas estén en la misma situación.
Magento queda pendiente de la respuesta de Adobe
StyleSmuggler vuelve a mostrar uno de los escenarios más delicados de la ciberseguridad empresarial: una vulnerabilidad explotada activamente antes de que exista un parche oficial del fabricante.
La prioridad para empresas, agencias y administradores que gestionen Magento es comprobar posibles indicadores de compromiso, estudiar las mitigaciones disponibles y aplicar inmediatamente la actualización oficial cuando Adobe publique una corrección específica.
Hasta entonces, conviene evitar una falsa sensación de seguridad. Tener Magento actualizado no basta frente a un día cero que todavía carece de parche, y cualquier sistema que haya estado expuesto durante la ventana de ataque merece una revisión específica.
