Introducción
El 4 de septiembre, un operador desconocido comprometió una tienda Magento Open Source 2.4.6-p15 que ya tenía aplicados los parches de julio y agosto de 2026. No hubo credenciales robadas, no hubo acceso previo: la cadena de explotación corrió sin autenticación y dejó un backdoor persistente en el servidor. Al día siguiente, Sansec publicó la advisory y alertó al ecosistema. Adobe, hasta el 6 de septiembre, no había emitido CVE, advisory, parche ni workaround. La próxima ventana de seguridad programada es el 8 de septiembre, y nadie garantiza que cubra este bug. Para los equipos que administran tiendas Magento, esto significa que no existe una actualización que instalar todavía, y que la única defensa inmediata es deshabilitar el vector de ataque.
Qué ocurrió
Sansec denominó StyleSmuggler a la cadena de explotación y documentó el ataque en dos etapas. En la primera, el atacante inyecta código PHP en un archivo que Magento escribe por sí mismo: un log de errores o un reporte de fallo. En la segunda, dispara el correo «Payment Transaction Failed Reminder» de la plataforma, que obliga a Magento a renderizar el mensaje y, en ese proceso, a incluir el archivo envenenado. El código se ejecuta durante el renderizado del email, así que no hace falta que nadie abra el correo ni que la entrega del mensaje funcione. Disrex Group, que atendió dos tiendas comprometidas y una tercera atacada sin brecha, identificó el punto de ejecución en tres archivos bajo setup/src/Magento/Setup/Module/Di/Code/, donde una directiva dentro del texto inyectado encadena clases internas de Magento hasta un include de ruta controlada por el atacante.
El dropper PHP intenta seis funciones de PHP en secuencia para spawnear un proceso, descarga el implant y lo lanza. El implant es un binario Rust estático, compilado para x86-64 y arm64, de aproximadamente 1,9 MB, instalado en ~/.local/share/.gvfsd/gvfsd-user bajo el home del usuario del sitio (no en el web root). Corre como [kworker/u:8:0], un nombre que pertenece a un thread real del kernel Linux, para pasar desapercibido en ps y top. Una entrada cron escrita directamente en /var/spool/cron/crontabs/ lo reinicia cada cinco minutos. En una de las tiendas comprometidas, esa misma línea aparecía 1.728 veces, y el implant la reescribía dentro del segundo posterior a cualquier intento de eliminación.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El riesgo es alto para cualquier tienda Magento expuesta a internet, pero la superficie real de impacto tiene matices que cambian la priorización. Sansec reprodujo la cadena completa en instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9. Disrex confirmó dos compromisos en producción: Store A corría 2.4.8 (con el módulo Sansec Shield instalado, activo y con licencia) y Store B corría 2.4.7-p2, un nivel de parche de agosto de 2024, ocho niveles por debajo del 2.4.7-p10 vigente. El punto que Disrex enfatizó: «El estado del parche fue irrelevante aquí.» Store A tenía Shield activo bloqueando otro tráfico malicioso en el momento del ataque, a las 23:10 UTC del 4 de septiembre, horas antes de que las reglas de bloqueo específicas para StyleSmuggler entraran en producción.
En una de las tiendas, el implant no generó una sola conexión saliente. Mantuvo 28 conexiones persistentes a la instancia Redis local en el puerto 6379 y leyó el almacenamiento de sesiones de Magento directamente desde ahí. Dos capturas de paquetes de más de 200 MB tomadas mientras el implant estaba activo no contenían un solo paquete hacia el host de descarga ni hacia la dirección C2 que Sansec listó. Esto rompe la premisa de que un egress firewall basta: el implant opera íntegramente dentro de la red interna del servidor. Disrex confirmó que no hubo movimiento lateral, no se crearon cuentas admin rogue, no se inyectaron skimmers de pago ni backdoors en la base de datos, y no se detectó exfiltración de datos. Ambas tiendas quedaron contenidas entre 11 y 14 horas después del primer contacto.
Detalles técnicos
El vector de envenenamiento del log no pasa por var/report/, donde Sansec coloca su marcador de verificación X_TRACE_. Disrex documentó que ambas infecciones pasaron por var/log/system.log, y que el marcador ya mutó: a la mañana del 5 de septiembre aparecía un header X-TRACE- seguido de diez caracteres hexadecimales; por la tarde, el mismo header sin la palabra TRACE. Una búsqueda por string exacto pierde las variantes. El artefacto en el log es un TypeError de array_merge() con un argumento entero, inmediatamente después del include del archivo envenenado.
Para la verificación en servidores Linux, los comandos que aplican:
# Buscar envenenamiento en ambos directorios, no solo var/report/
grep -rn «X.TRACE\|X-TRACE» /var/www/magento/var/report/ /var/www/magento/var/log/system.log
# Verificar presencia del implant (nombre disfrazado + ruta real)
ps aux | grep ‘\[kworker/u:8:0\]’
ls -la ~/.local/share/.gvfsd/gvfsd-user
# Revisar crontabs escritos directamente (no pasan por ‘crontab -e’)
cat /var/spool/cron/crontabs/*
# Confirmar conexiones anómalas a Redis (28 sesiones persistentes)
ss -tnp | grep 6379 | grep -i gvfsd
El binario es Rust, estáticamente linkeado y strippeado, lo que elimina symbols y dificulta el análisis sin reversing. Las dos arquitecturas (x86-64 y arm64) indican que el dropper selecciona el binario según el host. El repositorio de incidentes de Disrex, publicado el 5 de septiembre, aclara en su README que fue escrito con asistencia de IA durante un incidente en vivo, que las reglas Apache nunca se ejecutaron contra un servidor Apache real y que la mayoría de los comandos de limpieza están escritos pero no probados. Esa advertencia obliga a tratar las reglas como punto de partida para revisión manual, no como un drop-in.
Qué deberían hacer los administradores y equipos técnicos
Inmediato (próximas 2 horas):
Corto plazo (esta semana):
Seguimiento:
Conclusión
StyleSmuggler es un recordatorio incómodo de que en Magento la superficie de ataque no es solo un endpoint HTTP: es un log que la propia plataforma escribe, un email que la propia plataforma renderiza y una sesión en Redis que la propia plataforma mantiene abierta. La cadena funciona sin credenciales, sin interacción humana y sin tráfico de red saliente, lo que neutraliza buena parte del monitoreo estándar. La ausencia de CVE y de parche al 6 de septiembre deja a los equipos con un workaround parcial (deshabilitar GraphQL) y reglas de WAF escritas a las apuradas durante un incidente en vivo. Hasta que Adobe publique un fix verificado, la detección manual y la contención rápida son la única línea de defensa real.
Fuentes
- https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html