StyleSmuggler: el zero-day de Magento que ya entra en tiendas y todavía no tiene parche

Hay un zero-day sin parche en Magento y Adobe Commerce que ya se está usando para meterse en tiendas online. La empresa holandesa de seguridad Sansec lo publicó el 5 de septiembre de 2026, lo bautizó StyleSmuggler y avisó que los ataques arrancaron el 4. Permite ejecutar código en el servidor de la tienda sin usuario ni contraseña, y afecta a todas las versiones vigentes, incluida la 2.4.9.

Al momento de publicar esta nota —6 de septiembre, 11:38 UTC— Adobe no publicó aviso de seguridad, ni identificador CVE, ni parche: verificamos su índice de boletines de Adobe Commerce y lo más nuevo sigue siendo el APSB26-92 del 11 de agosto. Si tu tienda no corre sobre Magento o Adobe Commerce —si usás WooCommerce, Shopify, Tiendanube o PrestaShop—, ninguna de las fuentes que leímos la menciona como afectada, así que a priori esto no te toca; nadie publicó un desmentido formal, eso sí.

Qué es StyleSmuggler y por qué estar al día no alcanzó

StyleSmuggler es un zero-day de ejecución remota de código sin autenticar: el atacante no necesita una cuenta, ni robar una contraseña, ni engañar a nadie para que abra un archivo. Le manda peticiones a la tienda y termina corriendo programas en el servidor.

Sansec dice haber reproducido la cadena completa sobre instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9. Y el dato que más duele: la primera víctima confirmada corría 2.4.6-p15 con los parches de julio y agosto de 2026 aplicados y el chequeo security:patch-status en limpio. Es decir: el estado de parcheo, que es lo que se le exige a un administrador, estaba impecable.

El estado de parcheo fue irrelevante acá, que es la parte que los comerciantes más necesitan escuchar.

Disrex Group, empresa de hosting y desarrollo Magento, a The Hacker News (traducción del inglés)

Disrex no es un espectador: alojaba y respondió a dos de las tiendas comprometidas, y publicó su propio análisis, que es donde viven los comandos de detección. Buena parte del detalle fino de esos dos incidentes, en cambio, salió de las respuestas que la empresa le dio a The Hacker News, y así está atribuido acá. Que el descubridor y quien atendió el incidente describan lo mismo es lo que sostiene esta nota, porque Adobe todavía no dijo una palabra. Con una precisión: los incidentes son independientes, pero la lista de indicadores no del todo, porque Disrex dice haber cotejado la suya contra el aviso ya publicado de Sansec.

Conviene mirar de cerca ese par de tiendas, porque la frase se apoya en ellas. La primera corría 2.4.8 y era cliente de Sansec Shield, con el módulo instalado, activo y licenciado: cayó a las 23:10 UTC del 4 de septiembre, horas antes de que existieran las reglas para este fallo, mientras Shield bloqueaba otro tráfico malicioso contra la misma tienda. La segunda no era cliente y corría 2.4.7-p2, ocho niveles de parche por detrás del 2.4.7-p10 vigente. Sumada la víctima de Sansec —2.4.6-p15 al día—, el patrón se sostiene: en esa ventana, el nivel de parche no era la variable.

Cómo funciona: envenenar un log y hacer que Magento lo ejecute

El ataque tiene dos etapas, y la gracia perversa es que las dos las ejecuta Magento con sus propias herramientas.

• Etapa uno: envenenar. El atacante logra que Magento escriba código PHP dentro de un archivo que la propia aplicación genera —un reporte de error en var/report/ o, en los dos casos que investigó Disrex, directamente var/log/system.log—.
• Etapa dos: ejecutar. Una segunda petición empuja al sistema de plantillas hasta un rincón del compilador de inyección de dependencias que hace include de un archivo elegido por el atacante. Y include en PHP no lee: ejecuta. El log deja de ser texto y pasa a ser programa.

Sansec describe el disparador de la segunda etapa como el correo estándar de «Payment Transaction Failed Reminder», el aviso de pago rechazado. El detalle importante: nadie tiene que abrir ese mail. El código corre mientras Magento arma el mensaje, y el ataque funciona incluso si el correo nunca llega a enviarse.

Después viene la parte que ya no es Magento. La explotación exitosa larga un programa nativo de Linux —Disrex lo describe como un binario en Rust, estático, de alrededor de 1,9 MB— que se hace pasar por un hilo del kernel bajo el nombre [kworker/u:8:0], se copia a ~/.local/share/.gvfsd/gvfsd-user y se agenda en cron para revivir cada cinco minutos. Una tienda tenía esa línea de cron repetida 1.728 veces, y el proceso la volvía a escribir menos de un segundo después de borrarla.

Casi nueve horas sin defensa: la cronología

Esta es la parte que conviene mirar con calma, porque explica por qué «tener todo actualizado» no era una defensa disponible.

Entre el primer ataque y la primera regla específica pasaron casi nueve horas —Disrex las redondea a «unas ocho»— en las que no existía ni parche oficial ni firma de detección. Y la tienda que cayó a las 23:10 tenía Sansec Shield instalado, activo y licenciado: las reglas para este fallo todavía no existían, y la empresa dice que Shield sí estaba bloqueando otro tráfico malicioso contra esa misma tienda en ese momento. Sobre la fecha del 8 de septiembre: la afirmación es de Sansec, no de Adobe. Lo que sí pudimos comprobar en el índice oficial es que los últimos boletines de Commerce salieron en segundos martes —11 de agosto, 14 de julio, 12 de mayo—, y el segundo martes de septiembre de 2026 cae justo el 8. El día de la semana es regular; la periodicidad no tanto, porque en junio no hubo boletín. Y sobre todo: nadie confirmó que ese boletín vaya a cubrir este fallo.

Cómo revisar tu servidor sin gastar un peso

Sansec y Disrex publicaron chequeos de solo lectura. Se corren como el usuario del sistema de archivos de Magento y no modifican nada; adaptá las rutas a tu hosting.

• Procesos que se hacen los kernel. Un hilo real del kernel corre como root y no consume memoria residente. Un nombre entre corchetes bajo el usuario de la tienda, y con memoria de verdad, es el implante. Ojo con cómo lo buscás: el implante escribe esa cadena entre corchetes en su propia línea de comandos, así que hay que matchear contra args y no contra el campo comm, donde no aparece nada.
• Persistencia y archivos sueltos. Buscar entradas de cron con gvfsd o .kw_, y los directorios ~/.local/share/.gvfsd/, /tmp/.kw_* y /tmp/.gvfsd-*.
• Los dos directorios, no uno. El chequeo publicado por Sansec busca el marcador X_TRACE_ en var/report/. Disrex avisa que sus dos infecciones entraron por var/log/system.log y ese chequeo las habría pasado por alto: hay que mirar var/report/ y var/log/, buscando además cualquier apertura de PHP dentro de esos archivos.
• El registro de acceso, que es el que dice si te tiraron el exploit. Los tres chequeos anteriores encuentran un implante ya instalado; este sirve para el caso más común, el de la tienda que quiere saber si la atacaron. Disrex publica un grep sobre el access log que busca cuatro señales del ataque: styles[ o su versión escapada styles%5B, generatorClass, with_resolved y cdnflare.
• El marcador ya cambió. Disrex vio la cabecera disparadora con la forma X-TRACE- más diez caracteres hexadecimales a la mañana del 5 de septiembre, y la misma cabecera sin la palabra TRACE a la tarde. Conviene buscar la forma, no la cadena exacta.
• Un error de PHP que en realidad es una confesión. Un TypeError de array_merge() en system.log, justo después del include, es señal de que el exploit funcionó: el error ocurre después de que el archivo ya se ejecutó. Y hay una variante más sigilosa que no deja ni eso.

Tres advertencias que salen de los propios respondedores, y que valen más que cualquier consejo genérico:

• Un escaneo limpio no prueba que el servidor esté limpio. En una de las tiendas, eComscan —el escáner del propio Sansec— informó «limpio» once horas después de la infección, con 1.728 líneas de cron puestas. Según Disrex, la causa fue el alcance del escaneo y no una falla del escáner: estaba apuntado a la raíz del sitio y el implante vivía un directorio más arriba, en el home de la cuenta. La empresa dijo que confirmaría por separado el número de build de eComscan, así que ese punto todavía no está cerrado.
• El silencio en la red no prueba nada. En una de las dos infecciones el implante no abrió una sola conexión saliente: se quedó hablando con el Redis local de la tienda, en el puerto 6379, leyendo el almacenamiento de sesiones. Dos capturas de tráfico de más de 200 MB cada una no tenían un solo paquete ni hacia el host de descarga ni hacia el C2 que figuran en los indicadores.
• El hash del disco puede mentir. Disrex encontró que el binario que corría en memoria era una compilación distinta del archivo guardado en disco: si hay un proceso sospechoso vivo, hay que hashear también /proc/<pid>/exe.

Sobre esas dos últimas filas, un aviso de tamaño: Disrex contó 26 direcciones de origen distintas en sus dos tiendas y calculó que bloquear 88.216.72[.]181 —la única dirección de origen que figura en el aviso de Sansec— habría frenado menos de un cuarto del tráfico que vio. Las listas de IOC sirven para encontrar, no para blindar.

Qué se puede hacer mientras Adobe no publica el parche

No hay arreglo del fabricante para instalar. Lo que hay son capas, todas con letra chica, y ninguna reemplaza al parche oficial.

La segunda y la tercera fila —disable_functions y noexec— son las dos medidas que no dependen de entender la cadena, y las que Disrex pone por delante de todas sus propias reglas. Si tenés que elegir por dónde empezar, empezá por ahí.

Un párrafo aparte para los parches comunitarios, porque el entusiasmo de una madrugada de incidente merece una lectura fría. Los publicaron Disrex, el desarrollador ProxiBlue —que llegó a la misma solución por separado, algo que Disrex considera una corroboración fuerte de que va por buen camino— y la empresa Graycore. Tres advertencias antes de tocar nada: el parche de Disrex y el de ProxiBlue son el mismo arreglo y no se aplican uno encima del otro; la edición a mano se pierde en cada composer install, por eso Disrex la empaqueta como parche de Composer; y el módulo de Graycore, en la versión que estaba publicada en Packagist al momento de escribir esto, solo mitigaba un punto que ya fue removido, con un README que aclara que eso es endurecimiento y no un arreglo. El repositorio de Disrex, además, advierte esto antes de su primera instrucción:

Este repositorio fue escrito con asistencia de IA, durante un incidente en vivo, en unas pocas horas. No pasó por revisión y no lleva garantía de ningún tipo.

README del repositorio de mitigación de Disrex (traducción del inglés)

La misma advertencia aclara qué sí está apoyado en la realidad —las reglas del servidor web salen del tráfico de ataque capturado en una tienda comprometida— y qué no: las reglas de Apache nunca se corrieron contra un Apache vivo. Si vas a aplicar algo de todo esto, probalo en staging, hacé backup y dejá que un fallo del parche detenga el despliegue en lugar de pasarlo por alto.

Si encontrás un indicador, el orden importa

Acá es donde el instinto juega en contra. La guía de limpieza de Disrex es explícita en lo que no hay que hacer primero: no reiniciar el servidor —la copia en /proc puede ser el único binario que quede—, no borrar el archivo antes de preservar evidencia, y no correr composer install para «arreglar», porque pisa las marcas de tiempo que muestran qué se tocó.

El orden que recomiendan: confirmar, preservar evidencia, contener —primero la persistencia, después el proceso, al final los archivos—, buscar otras puertas traseras, y recién ahí rotar secretos: la clave de cifrado de app/etc/env.php, las contraseñas de administrador, las claves de API de los medios de pago y toda credencial de integración que viva en ese archivo. Como el implante leyó el almacenamiento de sesiones, también corresponde vaciarlo. Y hay un paso más que en América Latina conviene no saltear: evaluar el impacto, es decir a qué datos pudo acceder el proceso y si eso dispara obligaciones legales o contractuales de notificación. Después de todo eso, esperar más de un ciclo de cron de cinco minutos y volver a chequear, porque el bicho restauraba su persistencia casi al instante.

La parte tranquilizadora, y conviene decirla con la misma precisión: Sansec afirma que no tiene indicios de que la puerta trasera haya sido usada, y Disrex informó que en sus dos casos no encontró exfiltración de datos, ni cuentas de administrador nuevas, ni skimmer de tarjetas inyectado, ni puerta trasera en la base de datos. Los dos incidentes quedaron contenidos el mismo día. Eso es lo observado en dos tiendas, no una garantía para el resto.

Lo que todavía no se sabe

• Cuántas tiendas cayeron. Ninguna de las fuentes publicó un número.
• Si Adobe Commerce paga y la versión en la nube están afectadas. Sansec no publicó reproducción sobre ellas y Adobe no confirmó qué versiones alcanza el fallo.
• Dónde termina exactamente la cadena. Disrex y ProxiBlue apuntan a tres archivos del compilador de inyección de dependencias; ni Sansec ni Adobe confirmaron esa lectura.
• Si el boletín del 8 de septiembre lo cubre. Sansec lo plantea como incógnita, en sus palabras, y nosotros no encontramos calendario público de Adobe que lo anticipe.
• Qué pasa en la región. No hay datos de víctimas en América Latina, ni distribución geográfica publicada por nadie. Como el ataque no necesita autenticación, la exposición depende sobre todo de tener la tienda publicada en internet y no del país; pero eso es una posibilidad razonable, no un dato.

Los hostings Nexcess y Liquid Web publicaron el 5 de septiembre avisos idénticos diciendo que estaban revisando sus entornos y aplicando medidas preventivas. Ninguno de los dos afirmó tener clientes comprometidos ni haber reproducido el fallo por su cuenta.

¿Y esto qué significa para vos?

Si tu negocio no toca Magento, el valor de esta historia es otro y es bastante universal: la vulnerabilidad cruzó la frontera entre la aplicación y el sistema operativo. Magento escribió el archivo, Magento lo ejecutó, y lo que quedó corriendo fue un proceso de Linux fuera del directorio del sitio. Por eso un escaneo que solo mira la carpeta de la aplicación puede devolver «todo bien» mientras el bicho respira un piso más arriba.

La traducción práctica para cualquier PyME con algo publicado en internet: la separación de cuentas importó —en los dos casos el implante corrió como usuario sin privilegios y no llegó a ninguna otra tienda del mismo servidor—, y la señal más útil no vino de una herramienta cara sino de un correo raro que el dueño reenvió. Mirar el buzón sigue siendo una capa de seguridad.

Y una aclaración honesta, porque acá vendemos licencias: ningún antivirus de escritorio te cubre esto. Es un servidor Linux con PHP, no una PC con Windows. Quien te diga lo contrario te está vendiendo humo con descuento.

Preguntas frecuentes sobre StyleSmuggler

¿Me afecta si mi tienda es WooCommerce, Tiendanube o Shopify?

Las fuentes que leímos —Sansec, Disrex y la cobertura de The Hacker News— describen el fallo únicamente en Magento Open Source y Adobe Commerce, y ninguna menciona otras plataformas como afectadas. Eso no es lo mismo que un desmentido formal de nadie, pero no hay a la fecha ningún reporte que las involucre.

¿Tiene número de CVE?

Al 6 de septiembre, no: ninguna de las fuentes publicó identificador. Sin CVE asignado tampoco puede entrar al catálogo de vulnerabilidades explotadas de CISA, que se organiza justamente por ese número —consultamos la versión 2026.09.04, con 1.695 entradas, y las tres de Magento que figuran son viejas—. Es una ausencia de trámite, no una señal de que el problema sea menor: el zero-day de Chrome que cubrimos esta misma semana muestra el camino habitual: identificador asignado y versión corregida para instalar.

¿Administrás una tienda Magento? Contanos abajo ⬇️