stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) kit de IOC para Magento Open Source y Adobe Commerce. Detecta tiendas comprometidas, implantes en Rust, webshells en PHP, artefactos de persistencia e indicadores de compromiso conocidos.

Cobertura del parche oficial de Adobe — verifica esto antes de asumir que estás a salvo

Si estás en una versión más antigua y no soportada, Adobe no te enviará un parche aunque seas igualmente explotable. Consulta docs/PATCHING.md para tus opciones.

Esta información cambia rápido. Contrasta con las fuentes primarias antes de actuar: el aviso de Sansec y el boletín de Adobe. Consulta docs/TIMELINE.md para un registro continuo y cita tus fuentes cuando actualices cualquier cosa aquí.

Qué es realmente StyleSmuggler

El propio parámetro styles de GraphQL de Magento y su escaneo de archivos basado en inyección de dependencias se abusan como una primitiva de ejecución diferida basada en archivos de dos etapas, en lugar de un único punto de inyección obvio:

1. Envenenar. Los datos controlados por el atacante llegan a un archivo de registro o informe generado por Magento (var/log/system.log mediante un código de tienda no válido que Magento registra textualmente, o var/report/<hash>), introducidos de contrabando a través del parámetro styles[] de GraphQL, un encabezado de solicitud mutado o (para el segundo atacante no relacionado a continuación) el encabezado Store:.
2. Detonar. El atacante activa el correo electrónico estándar de "Recordatorio de transacción de pago fallida" de Magento. Renderizar ese correo (la ruta getProcessedTemplate de Magento) recorre una ruta de código que permite que el propio escáner de código/DI de Magento include() el archivo envenenado, ejecutando el PHP del atacante. No necesitas abrir el correo — renderizarlo del lado del servidor es suficiente — y la cadena puede activarse incluso cuando falla la entrega del correo.

Una señal de alerta temprana fácil, sin herramientas: un correo electrónico corrupto de "Recordatorio de transacción de pago fallida" en tu bandeja de entrada con etiquetas {{var ...}} crudas y sin renderizar y una dirección de cliente que termina en .invalid. Esto suele ser la primera señal visible, antes de que alguien revise un registro.

Las actualizaciones de Sansec confirmaron una segunda ruta de explotación independiente para la misma campaña del implante Rust: incluso las tiendas que movieron el almacenamiento de sesiones fuera de Redis y hacia la base de datos seguían comprometidas — el segundo intento del mismo operador tuvo éxito segundos después usando un archivo subido mediante la función de opciones personalizadas del cliente de Magento en su lugar. Mover el almacenamiento de sesiones no es un parche por sí solo.

Por separado, el 7 de septiembre, Sansec encontró un atacante completamente no relacionado usando el mismo punto de entrada de StyleSmuggler para una carga útil mucho más simple: una web shell PHP colocada en la caché de imágenes de productos de Magento (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), precedida por una sonda de reconocimiento que oculta su carga útil en el encabezado HTTP Store: y exfiltra sus hallazgos a través de DNS en lugar de una respuesta HTTP. Esto es "herramientas estándar", según Sansec — no una campaña sostenida — pero significa que un solo host vulnerable puede albergar dos intrusiones no relacionadas a través de una sola falla. Limpiar el implante Rust no significa que tu tienda esté limpia.

El implante Rust en sí también ha evolucionado: la compilación original que se hacía pasar por [kworker/u:8:0] (4 sept) fue seguida por una compilación que se hacía pasar por fc-cache v2.1.4 (6 sept) que hace balizamiento disfrazado de tráfico NTP, y luego un redespliegue que se hacía pasar por chronyd v2.1.5 (7 sept) del mismo implante, mismo ID de agente — evidencia de que el atacante está iterando activamente para evadir cualquier detección que publiques. Sansec afirma que aún no ha visto evidencia de que este implante se haya armado más allá de persistencia/reconocimiento — no lo leas como tranquilidad dado el web shell funcional del atacante no relacionado en la misma ruta de acceso.

Consulta docs/FAQ.md para respuestas rápidas, docs/VULNERABILITY.md para el informe técnico completo y las fuentes, docs/PATCHING.md para aplicar el parche oficial de Adobe, y docs/INCIDENT_RESPONSE.md para saber qué hacer si el escáner encuentra algo.

Inicio rápido

1. Parchea, si tu versión está cubierta:

2. Escanea en busca de compromiso existente independientemente del estado del parche — parchear detiene la nueva explotación, no limpia un backdoor o web shell existente:

O la versión en Python para salida estructurada (JSON), p. ej., para alimentar un SIEM:

Ambos scripts son de solo lectura por defecto — detectan e informan, no matan procesos ni eliminan archivos a menos que pases --remediate, porque la limpieza prematura destruye evidencia forense (consulta docs/INCIDENT_RESPONSE.md).

Qué comprueba el escáner

• Artefactos conocidos de persistencia en el sistema de archivos en las tres compilaciones observadas del implante Rust:
  • Compilación [kworker/u:8:0]: ~/.local/share/.gvfsd/gvfsd-user, sus archivos de bloqueo, /tmp/.kw_*, /tmp/.gvfsd_*
  • Compilación fc-cache v2.1.4 (6 sept): ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • Compilación chronyd v2.1.5 (7 sept): /tmp/.chrony-<8hex>/chronyd
• Las entradas de crontab auto-restauradoras que el implante escribe directamente en el spool de cron — cada 5 minutos para la compilación gvfsd-user, dos veces por hora (13,43 * * * *) para fc-cache
• Un proceso suplantador llamado [kworker/u:8:0], fc-cache o chronyd que no es propiedad de root (o, para fc-cache/chronyd, no coincide con el binario real del sistema)
• SHA-256 de los binarios en disco y de la imagen /proc/<pid>/exe en vivo (los dos pueden diferir — se ha observado que el implante se actualiza a sí mismo en memoria)
• Archivos de registro/informe envenenados (var/log/system.log, var/report/) en busca de PHP inyectado, las dos formas conocidas de encabezados desencadenantes (X-TRACE-<10hex> y X-<12hex>), y los marcadores de campaña del segundo atacante no relacionado (ss5_/ss6_<hex>) y el dominio canario DNS (oast.site)
• Marcadores de respuesta de prueba de ejecución (MG<20hex>::...::/MG<20hex>) dejados en los registros cuando la carga útil realmente se ejecutó
• Archivos PHP bajo pub/media — que nunca deberían contener PHP ejecutable en una tienda Magento configurada correctamente — que coincidan con el patrón de colocación del web shell del segundo atacante
• Conexiones establecidas con los hosts C2/de descarga publicados — incluido el balizamiento con forma de NTP de la compilación fc-cache/chronyd hacia ntp.timesync.to:123/UDP (y respaldos), y sus llamadas HTTP simples a servicios públicos de consulta de IP
• Conteos anómalos de conexiones Redis locales (se ha observado recolección de sesiones enteramente a través de 127.0.0.1:6379, con cero tráfico C2 saliente — una red silenciosa no es una limpia) — y ten en cuenta que mover las sesiones fuera de Redis por sí solo no cierra el segundo vector de explotación basado en subida de archivos

Lista completa de indicadores con fuentes: iocs/.

Parcheo y mitigación

1. Aplica el hotfix oficial de Adobe (VULN-39341 / APSB26-146) si tu versión está cubierta — consulta docs/PATCHING.md para los identificadores, dónde obtenerlo y cómo aplicarlo. Esta es ahora la prioridad, por delante de las mitigaciones provisionales siguientes.
2. Si no puedes parchear de inmediato, o tu versión no está cubierta, usa las mitigaciones provisionales en mitigations/:
   • Bloquea o limita la tasa de la ruta de entrega de styles[] de GraphQL (nginx / Apache)
   • Bloquea la ejecución de PHP bajo pub/media/pub/static (nginx / Apache) — defensa dirigida contra la técnica de web shell del segundo atacante no relacionado
   • Reglas ModSecurity para inspección del cuerpo POST y fail2ban como respaldo reactivo
   • Consulta mitigations/README.md para las limitaciones de alcance — ninguna de estas cierra el vector de opciones personalizadas del cliente ni la entrega mediante el encabezado Store: del segundo atacante.
3. Ejecuta el escáner de compromiso independientemente del estado de parche/mitigación. Parchear y mitigar detienen la explotación nueva; ninguno limpia un backdoor o web shell ya colocado.
4. Si el escáner encuentra algo, trata el host como completamente comprometido, no solo "con backdoor presente". La ejecución de código como el usuario del sitio expone todo lo que ese usuario puede leer, empezando por app/etc/env.php. Como mínimo, después de la contención: vacía el almacenamiento de sesiones (Redis y/o BD), rota la crypt/key de Magento, todas las contraseñas de administrador (e invalida las sesiones de administrador existentes), la contraseña de la base de datos, cada clave de API del proveedor de pagos y otras credenciales de integración en env.php, y cualquier clave SSH/despliegue que el usuario del sitio pudiera leer. También verifica la tabla admin_user en busca de una cuenta rogue y los directorios pub/media/ / pub/static/ / de temas en busca de webshells colocadas — tanto las del implante Rust como las del segundo atacante no relacionado — antes de considerar una tienda limpia. Pasos ordenados completos: docs/INCIDENT_RESPONSE.md.

Estructura del repositorio

Términos buscados con frecuencia

CVE-2026-75650, APSB26-146, VULN-39341, día cero de Magento 2026, día cero de Adobe Commerce, parche StyleSmuggler, vulnerabilidad GraphQL de Magento, RCE del parámetro styles de Magento, malware gvfsd-user, backdoor Magento fc-cache, malware Magento chronyd, malware del proceso kworker de Magento, secuestro de sesión Redis de Magento, RCE no autenticado de Magento septiembre 2026, exploit de Magento 2.4.9, eliminación de backdoor de Adobe Commerce, web shell pub/media de Magento, eComscan StyleSmuggler, Sansec Shield StyleSmuggler.

Fuentes y procedencia

Cada indicador en este repositorio se remonta a una fuente publicada y citada — principalmente el aviso de Sansec (actualizado al menos hasta el 2026-09-07 20:50 UTC), el boletín APSB26-146 de Adobe, e informes comunitarios de respuesta a incidentes de respondedores que manejaron infecciones en vivo. Consulta la cita al final de cada archivo en iocs/.

No trates nada aquí como exhaustivo o definitivo. Los IOC (encabezados desencadenantes, cadenas de user-agent, disfraces de implantes y ahora los marcadores de campaña de un segundo atacante) ya han cambiado múltiples veces en días desde la divulgación; espera que cambien de nuevo. Compara formas y comportamientos, no solo cadenas literales, siempre que los scripts te lo permitan.

Contribuciones

¿Has visto una variante, un hash nuevo, una dirección de origen nueva o un falso positivo? Abre un issue o PR con lo que observaste y cómo lo observaste. Por favor:

• Redacta los detalles de identificación de tu propia organización antes de compartir.
• No publiques cargas útiles de exploits ni solicitudes desencadenantes funcionales aquí — solo indicadores y lógica de detección.
• Reporta la vulnerabilidad subyacente en sí a Sansec y a Adobe PSIRT, no a este repositorio.

Licencia

MIT para el código en este repositorio (consulta LICENSE). Los datos de indicadores se proporcionan "tal cual" para uso defensivo, con las fuentes indicadas en todo momento.

Aviso legal

Esto es una herramienta defensiva no oficial construida por la comunidad, no un producto de Adobe o Sansec, y no está afiliada a ninguno de los dos. Se proporciona sin garantía. El parche oficial de Adobe (APSB26-146) se ha publicado, pero la cobertura se limita a versiones de producto específicas — consulta el boletín de seguridad de Adobe directamente antes de asumir que tu instalación está cubierta o parcheada.