Se ha detectado una vulnerabilidad sin parchear llamada StyleSmuggler en Magento Open Source y Adobe Commerce que permite ejecutar código malicioso sin autenticación. El ataque instala una puerta trasera persistente en el servidor, afectando a múltiples versiones actuales. Como medida temporal, se recomienda desactivar GraphQL o aplicar mitigaciones externas hasta que Adobe publique una solución oficial.





Los atacantes están explotando una nueva vulnerabilidad sin parchear en Magento Open Source y Adobe Commerce que les permite ejecutar código malicioso en el servidor de una tienda online sin necesidad de iniciar sesión, según informó la empresa holandesa de seguridad de comercio electrónico Sansec en un aviso publicado el 5 de septiembre [https://sansec.io/research/stylesmuggler].

Sansec, que descubrió el fallo y lo llamó StyleSmuggler, afirmó que los ataques comenzaron el 4 de septiembre. "Sansec publica esto anticipadamente porque las tiendas están siendo comprometidas en este momento", señaló la empresa.

A fecha de 6 de septiembre, Adobe no ha publicado ningún aviso, identificador CVE, parche o solución alternativa, y su índice de boletines de seguridad de Adobe Commerce [https://helpx.adobe.com/security/products/magento.html] no muestra nada después de la actualización del 11 de agosto.

Un ataque exitoso otorga al atacante la ejecución de código en el servidor de la tienda e instala una puerta trasera (backdoor) persistente. Sansec afirmó que todas las versiones actuales están afectadas, incluida la 2.4.9, y que reprodujeron la cadena completa sin autenticación en instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9.

Su primera víctima utilizaba la versión 2.4.6-p15 con las actualizaciones de seguridad de julio y agosto de 2026 de Adobe aplicadas, que es el nivel de parche más reciente que Adobe ofrece para esa línea de lanzamiento y que el boletín de agosto de Adobe [https://helpx.adobe.com/security/products/magento/apsb26-92.html] etiqueta como 2.4.6-2026-aug.

Sansec no ha publicado una reproducción en Adobe Commerce ni en Adobe Commerce on Cloud, y Adobe no ha confirmado qué versiones están afectadas. Sansec tampoco ha dicho cuántas tiendas han sido comprometidas.

El consejo provisional de los investigadores para las tiendas que no utilicen su producto Shield es deshabilitar GraphQL hasta que Adobe publique una solución temporal.

Disrex Group, una empresa de hosting y desarrollo de Magento que respondió a dos de las tiendas comprometidas, señala que las tiendas "headless" y las aplicaciones web progresivas (PWA) requieren GraphQL, mientras que la mayoría de las tiendas clásicas y Hyvä no.

Próximos pasos y evidencias

La próxima versión de seguridad programada de Adobe es el 8 de septiembre, dijo Sansec, y aún no se sabe si esa versión cubrirá este error.

Los hallazgos de Disrex son evidencia independiente de la explotación fuera de Sansec. En un repositorio de respuesta a incidentes [https://github.com/disrex-group/stylesmuggler-mitigation] publicado el 5 de septiembre, la empresa afirmó que gestionó dos tiendas comprometidas el 5 de septiembre y una tercera que fue atacada pero no vulnerada, y que sus reglas de servidor web se basan en el tráfico de ataque capturado en una de las tiendas comprometidas.

Esa tienda ejecutaba Magento 2.4.7-p2, un nivel de parche de seguridad que el historial de versiones de Adobe [https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions] data de agosto de 2024, ocho niveles por detrás de la actual 2.4.7-p10. La tienda que Disrex etiqueta como "Tienda A" era cliente de Sansec Shield y fue atacada a las 23:10 UTC del 4 de septiembre, horas antes de que las primeras reglas de bloqueo de Sansec entraran en vigor.

El repositorio incluye su propia advertencia. "Este repositorio fue escrito con asistencia de IA, durante un incidente en vivo, en pocas horas", dice su README, añadiendo que no ha sido revisado, que sus reglas de Apache nunca se ejecutaron contra un servidor Apache real y que la mayoría de sus comandos de limpieza fueron escritos en lugar de ejecutados.

Los indicadores de Sansec describen el implante como un proceso en segundo plano disfrazado bajo [kworker/u:8:0], un nombre que pertenece a un hilo del kernel de Linux, con un binario instalado en ~/.local/share/.gvfsd/gvfsd-user bajo el directorio personal del usuario del sitio en lugar de la raíz web, y una entrada de cron que lo reinicia cada cinco minutos.

Disrex describió el binario como un programa de Rust vinculado estáticamente y "stripped" de aproximadamente 1.9 MB construido para x86-64 y arm64, y dijo que la entrada de cron se escribe directamente en el archivo spool bajo /var/spool/cron/crontabs/, por lo que el registro del sistema no muestra el reemplazo de crontab.

Una tienda tenía la misma línea 1,728 veces, y el implante la volvía a añadir un segundo después de ser eliminada.

En una de las dos tiendas, el implante no realizó ninguna conexión saliente. Mantenía 28 conexiones a la propia instancia de Redis de la tienda en el puerto 6379. Leyó el almacenamiento de sesiones de Magento desde allí, dijo Disrex, y ninguna de sus dos capturas de paquetes, cada una de más de 200 MB, contenía un solo paquete hacia el host de descarga o la dirección de comando y control que Sansec enumeró.

Sansec dijo que para los clientes de Shield atacados antes de que sus reglas entraran en vigor, no tiene indicios de que la puerta trasera haya sido utilizada realmente, y recomendó rotar las credenciales de Magento donde se haya identificado el proceso.

El ataque funciona en dos etapas, según el esquema de Sansec. Primero planta código PHP en un archivo que el propio Magento escribe, por ejemplo, al generar un informe de fallos. Luego hace que Magento ejecute ese archivo activando el correo electrónico estándar de la plataforma "Recordatorio de transacción de pago fallida". El código se ejecuta mientras Magento renderiza el mensaje, por lo que nadie tiene que abrirlo, y el ataque puede tener éxito incluso si la entrega del correo electrónico falla.

Sansec aún no ha publicado la cadena completa del exploit y dijo que el desglose de la cadena, el dropper y el implante vendrán en una actualización.

La lectura de Disrex sobre la cadena, publicada en un análisis del mecanismo [https://github.com/disrex-group/stylesmuggler-mitigation/blob/main/HOW-IT-WORKS.md] junto con sus reglas, es que una directiva dentro del texto inyectado impulsa una secuencia de clases propias de Magento hacia un código que existe únicamente para servir al compilador de inyección de dependencias de línea de comandos.

Ese código termina incluyendo una ruta de archivo elegida por el atacante: el log envenenado un momento antes. El dropper PHP ejecutado intenta seis funciones PHP en orden para iniciar un proceso, luego descarga y lanza el implante. Disrex menciona tres archivos bajo setup/src/Magento/Setup/Module/Di/Code/ como el punto donde termina la cadena. Sansec no ha confirmado esa lectura y Disrex no publica la solicitud ensamblada.

Dos ubicaciones son importantes para la primera etapa. La comprobación publicada por Sansec busca en var/report/ el marcador X_TRACE_. Disrex dijo que ambas infecciones fueron envenenadas a través de var/log/system.log en su lugar y habrían pasado desapercibidas con esa comprobación, por lo que es necesario buscar en ambos directorios.

El marcador ya ha variado: Disrex vio un encabezado de activación de la forma X-TRACE- seguido de diez caracteres hexadecimales la mañana del 5 de septiembre y el mismo encabezado sin la palabra TRACE por la tarde, por lo que la búsqueda debe coincidir con la forma más que con la cadena exacta.

Un TypeError de array_merge() con un argumento entero en system.log, inmediatamente después del "include", es evidencia de que el exploit tuvo éxito, dijo Disrex. Sin embargo, una variante más sigilosa devuelve un array vacío y no deja nada en el log.

Para el proceso, Disrex dijo que un hilo genuino del kernel es propiedad de root y no tiene memoria residente, por lo que un nombre entre corchetes en el usuario del sitio con uso de memoria real es el implante. El implante establece su línea de comandos como la cadena literal entre corchetes, por lo que una comprobación escrita contra el campo comm del proceso no coincide con nada.

Disrex también descubrió que el binario ejecutándose en memoria en una tienda era una compilación diferente al archivo en disco, y aconseja realizar el hash del proceso en ejecución desde /proc/<pid>/exe así como del archivo. Ráfagas inesperadas de correos de "Recordatorio de transacción de pago fallida" son una razón para investigar, dijo Sansec, aunque los pagos rechazados legítimos generan la misma notificación.

Los siguientes indicadores han sido publicados por Sansec y en la lista de indicadores de Disrex [https://github.com/disrex-group/stylesmuggler-mitigation/blob/main/IOC.md]:

- Proceso: [kworker/u:8:0] propiedad de un usuario que no sea root
- Archivo: ~/.local/share/.gvfsd/gvfsd-user
- Archivo: ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
- Archivo: /tmp/.gvfsd_<8hex>.lock
- Archivo: /tmp/.kw_<random><random>
- Cron: */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user, con una variante que apunta a /tmp/.kw_
- SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (muestra de Sansec)
- SHA-256: 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (en disco en ambas tiendas de Disrex)
- SHA-256: 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (ejecutándose en memoria en una tienda de Disrex)
- Dominio: 247.cdnflare[.]xyz (host de descarga de malware)
- IP: 99.84.67[.]186:443 (comando y control sobre WebSocket y TLS, según Sansec)
- IP: 88.216.72[.]181 (fuente del atacante, según Sansec)
- IP: 5.181.86[.]133 (fuente del atacante enviando en masa, según Disrex)

Sansec recomienda su escáner eComscan para detectar el implante, y dijo que la versión 1.9.7 terminará el proceso para los clientes de Shield.

Disrex informó el resultado opuesto para una tienda: eComscan se ejecutó con sus comprobaciones de procesos en segundo plano y tareas programadas habilitadas mientras el implante estaba activo, con 1,728 líneas de cron presentes, y reportó la tienda como limpia. Disrex no dijo qué versión de eComscan se ejecutó ni cuándo.

No hay un parche del proveedor para instalar. Hasta que Adobe envíe uno, las opciones son el cierre temporal de GraphQL de Sansec; tres mitigaciones no oficiales publicadas por Disrex, ProxiBlue y Graycore; y dos configuraciones de servidor que no dependen del fallo.

Disrex publicó reglas de nginx y Apache que bloquean las solicitudes que llevan los parámetros del exploit en la cadena de consulta de la URL. Su propia prueba en una tienda real mostró el límite: los mismos parámetros enviados en un cuerpo POST llegaron a PHP, al igual que un cuerpo JSON, porque nginx y Apache inspeccionan solo la cadena de consulta, dijo Disrex. Disrex describe las reglas como una forma de detener la campaña tal como se ejecuta actualmente, más que la vulnerabilidad en sí.

La mitigación principal de Disrex añade una comprobación a tres métodos en los escáneres de código de inyección de dependencias de Magento, evitando que se ejecuten fuera de la línea de comandos. La edición manual es revertida por cada "composer install", por lo que Disrex también lo entrega como un parche de fuente de composer-patches [https://github.com/disrex-group/stylesmuggler-mitigation/blob/main/patches/README.md] que se reaplica al desplegar y, según indica, se aplica sin cambios desde la 2.4.6 hasta la 2.4.9.

Uno de los tres archivos, ClassesScanner.php, es llamado a través de HTTP por al menos un módulo de terceros, mageplaza/module-admin-permissions, y protegerlo rompe la pantalla de administración de ese módulo, por lo que Disrex dice a los administradores que busquen en su directorio vendor antes de tocarlo.

El protector fue probado en un entorno de pruebas en lugar de dentro de una tienda en funcionamiento, y Disrex dice que no es una solución completa por sí sola. Un usuario de GitHub, ProxiBlue, publicó el mismo protector el 5 de septiembre, junto con tres parches no oficiales [https://gist.github.com/ProxiBlue/07373c92c8c70dc746bbfdcd1f07b789]. Ni Sansec ni Adobe han confirmado que estos escáneres sean donde termina la cadena.

Graycore, LLC publicó un módulo de Magento [https://github.com/graycoreio/magento2-style-smuggler-patch] en GitHub y Packagist el 5 de septiembre cuyo código actual, dice Graycore, refuerza tres puntos de la cadena: la directiva de bloque de plantilla de correo electrónico rechaza bloques de backend, el generador de URL de fila de cuadrícula comprueba una clase antes de construirla y las etiquetas de apertura de PHP en los informes de error fatal de la Web API están rotas.

La versión en Packagist al momento de escribir esto era un lanzamiento anterior cuya única mitigación se dirigía a un resolutor de GraphQL de PayPal que ha sido eliminado desde entonces. El README dice "Eso es un refuerzo, no una solución" y advierte que otras rutas a través de la vulnerabilidad permanecen abiertas y que una tienda puede estar ya comprometida.

Dos configuraciones de servidor no dependen en absoluto de conocer la cadena, dijo Disrex. En una de sus dos tiendas, las primeras cuatro de las seis funciones PHP que el dropper intentó estaban deshabilitadas; proc_open no lo estaba y el dropper la usó para iniciar el implante, y open_basedir no hizo nada para contener el proceso hijo.

Añadir proc_open a las disable_functions de PHP, y montar /tmp, /var/tmp y /dev/shm con noexec para que un binario descargado no pueda ejecutarse, son las capas que Disrex coloca antes de cada regla en su repositorio.

Para una tienda que ya esté infectada, la guía de limpieza de Disrex [https://github.com/disrex-group/stylesmuggler-mitigation/blob/main/CLEANUP.md] establece el orden: preservar la evidencia primero, eliminar la entrada de cron antes de matar el proceso porque el proceso la restaura, no reiniciar porque la copia bajo /proc puede ser el único binario restante, y no ejecutar "composer install" para limpiar porque sobrescribe las marcas de tiempo que muestran qué fue tocado.

Luego recomienda vaciar el almacenamiento de sesiones ya que el implante lo leyó, y rotar la crypt/key en app/etc/env.php, así como cada contraseña de administrador, cada clave API de proveedor de pago y cada otra credencial de integración en ese archivo.

Los proveedores de hosting Nexcess y Liquid Web publicaron avisos de incidentes idénticos el 5 de septiembre, afirmando que estaban revisando sus entornos de servidor e implementando medidas preventivas [https://status.nexcess.net/].

Ninguno afirma un compromiso confirmado de clientes o su propia reproducción del fallo. Disrex registró 26 direcciones de origen distintas en sus dos tiendas, dos de ellas infraestructuras de hosting enviando en masa y el resto un grupo de proxies residenciales enviando de dos a seis solicitudes cada una, y dijo que bloquear la única dirección de atacante en el aviso de Sansec habría detenido menos de una cuarta parte del tráfico que vio. Ninguna fuente ha identificado a los atacantes.

Fuente:
THN