StyleSmuggler ya tiene parche: Adobe cerró el zero-day de Magento con un hotfix

El zero-day de Magento y Adobe Commerce que ya se estaba usando para meterse en tiendas online ya tiene parche. 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. El 7 de septiembre Adobe publicó el boletín APSB26-146, le asignó el identificador CVE-2026-75650 y lo puntuó CVSS 10.0, la nota máxima.

Verificado por última vez el 13 de septiembre, 15:04 UTC: el arreglo existe y es un hotfix, no una versión nueva. Pero parchear no alcanza y el orden importa — un parche no limpia un servidor que ya fue comprometido, y Adobe pide además rotar la clave de cifrado y todas las credenciales que esa clave protegía. 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í.

Actualización del 17 de septiembre de 2026. Al releer el 17 de septiembre el informe de Sansec, encontramos tres cambios que te tocan. La página no dice cuándo los hizo: su sello «Last updated» sigue en el 14 de septiembre. Primero, cambió el comando para buscar PHP en la carpeta de medios: ahora es find -L pub/media -type f -name '*.php'. Sansec no explica por qué; lo que sí sabemos es qué hacen esas opciones de find: -L sigue los enlaces simbólicos y -type f se queda con los archivos. Si ya corriste la versión anterior, corré esta; ya la cambiamos en los chequeos de abajo. Segundo, sumó huellas que quedan en var/log/exception.log, que según Sansec sobrevive a la rotación de los registros de acceso, y las huellas de los correos de pago fallido que el atacante dispara con sus herramientas. Tercero, anotó en su cronología sondeos fallidos de un atacante el 23 de agosto, doce días antes de la primera explotación confirmada, y en su lista de indicadores sumó una variante «de agosto» que apunta a los archivos de sesión. Las huellas y la variante van en la tabla de lo que vimos el 17; el 23 de agosto, en la cronología. Qué cambia para vos: si revisás logs y correos, no arranques el 4 de septiembre; mirá también agosto (por qué).

Actualización del 14 de septiembre de 2026. Sansec amplió su informe con otra tienda, comprometida el 9 de septiembre, donde después de entrar se usaron otras herramientas: gs-netcat, del Global Socket Toolkit, y WraithC2, un troyano de acceso remoto de código abierto, más un include remoto metido en un archivo del propio Magento. En esa misma tienda lista también un skimmer guardado en la base de datos, como puerta trasera secundaria y sin decir por dónde entró. Qué cambia para vos: son otros procesos, otros archivos y otros servidores, así que conviene repasar la revisión con los indicadores nuevos, que van en una tabla aparte. Y el consejo de mirar los correos de pago fallido tiene ahora dos salvedades, las dos de Sansec: una tienda ya parcheada sigue recibiendo ese aviso, así que su llegada no prueba que te hayan entrado, y hay una variante del ataque que no pasa por el correo, así que su ausencia tampoco prueba que estés limpio.

🔄 Actualización del 13 de septiembre de 2026. Tres novedades. CISA ya incluye CVE-2026-75650 en su catálogo de vulnerabilidades explotadas conocidas, con fecha de alta el 8 de septiembre. Adobe actualizó el 11 de septiembre la nota del hotfix: ya no advierte que solo lo probó en las versiones -2026-aug, lo declara compatible con todas las versiones entre la 2.4.4 y la 2.4.7 y publica una tabla con archivos de parche por versión. Y el índice de boletines de Adobe Commerce, que iba atrasado, ya lista el APSB26-146, debajo de otro boletín: el APSB26-138 del 8 de septiembre, que corrige otros fallos con un parche de seguridad de septiembre. Ese parche no trae el hotfix: Adobe pide aplicar los dos. Aparte, en su informe, que da por actualizado el 13 a las 10:00 UTC, Sansec lista dos direcciones de origen y un dominio de exfiltración que nuestra tabla no tenía: si ya revisaste tu servidor, buscalos. Actualizamos la sección del parche —incluido qué hacer si tu versión no figura en la tabla de Adobe—, los indicadores, lo que todavía no se sabe y la pregunta sobre el CVE.

🔄 Actualizado el 8 de septiembre de 2026. Adobe publicó el parche el 7 de septiembre a las 20:20 UTC, según el sello que le pone Sansec, y lo hizo fuera de su calendario habitual. Qué cambia para vos:

• Hay algo para instalar, y no es una actualización normal. Es el hotfix VULN-39341, que se aplica como parche de composer y no como versión nueva. Cómo se aplica y cómo se verifica.
• Adobe pide rotar claves y credenciales, no solo parchear. Es la parte que más fácil se saltea y la que no se puede hacer después sin volver a empezar. Qué hay que rotar exactamente.
• Si revisaste tu servidor y te dio limpio, ese resultado sigue sin significar lo que parece. El implante se cambió el nombre dos veces, apareció un segundo atacante y el chequeo rápido del cron dejó de alcanzar. Qué cambió, en detalle · cómo cambió el orden de limpieza.

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 la parte de esta nota que cuenta el ataque: hasta la noche del 7 de septiembre Adobe no había publicado una línea propia sobre el fallo, y lo único que se le conocía era una respuesta privada contada por Sansec. Eso cambió con el boletín: para el parche, las versiones afectadas y la rotación de credenciales, la nota se apoya en los documentos propios de Adobe; para la mecánica del ataque y los indicadores, sigue apoyándose en Sansec y Disrex. 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.

Actualizado el 14 de septiembre: Sansec sumó una sección que titula «Execution without the email», ejecución sin el correo. Ahí la primera etapa manda el código PHP en la cadena de consulta —lo que va después del ?— de /paypal/transparent/response/; la petición provoca el error No such entity with cartId = 0 y Magento guarda la petición entera, cadena de consulta incluida, en un reporte de var/report/. La segunda etapa va contra /graphql y apunta a ese reporte. En intentos posteriores apuntó a var/log/system.log y a var/log/exception.log: para Sansec, cualquier archivo al que el usuario web pueda agregarle contenido es un blanco.

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.

Eso describe la primera compilación, y sigue siendo válido para ella. Pero el implante cambió de disfraz dos veces en dos días, y cada mudanza rompe una de las señales que la gente estaba usando para buscarlo:

• 6 de septiembre — la variante fc-cache. Las compilaciones de ese día (arm64 y x86-64) usan fc-cache como nombre de proceso en lugar de [kworker/u:8:0], se copian a ~/.cache/fontconfig/fc-cache, escriben el PID en /tmp/.fc_<8hex>.lock y cambian la cadencia del cron: 13,43 * * * *, dos veces por hora en vez de cada cinco minutos. El C2 también se mudó, a ntp.timesync[.]to por UDP al puerto 123, con dos dominios de reserva.
• 7 de septiembre — la variante chronyd, y esta es la incómoda. Un comerciante reportó otro nombre de proceso más en un servidor que ya tenía la compilación anterior: a las 09:50 UTC el implante se volvió a soltar y se relanzó como chronyd, que es el nombre real del demonio NTP en casi todas las distribuciones de Linux. Sansec aclara que el identificador de agente venía del mismo implante, así que es uno solo cambiándose el nombre, no una segunda infección.

La elección de chronyd no es casual, y Sansec lo dice sin vueltas: está pensada para ganarle a la búsqueda obvia. Cualquiera que revise tráfico UDP al puerto 123 va a sentir la tentación de excluir chronyd por ser el servicio legítimo de hora, y esa exclusión tapa la variante entera. Dos detalles la delatan igual: manda nueve datagramas de 48 bytes separados por unos 10 milisegundos, cada 60 segundos —un cliente real manda uno—, y los marca todos como NTPv4 modo servidor, algo que un cliente no tiene motivo para hacer nunca.

Y el detalle que más cambia la rutina de revisión: en el host donde Sansec la vio primero, esta variante se relanzó sola, sin entrada de cron —su proceso padre era el PID 1—. Traducido: un crontab vacío dejó de ser evidencia de que el servidor está limpio. Pero tampoco alcanza con dar por hecho lo contrario: el mismo 7 de septiembre Sansec corrigió el informe para avisar que la persistencia varía entre hosts, y que en otra tienda el mismo binario sí agendó 57,27 * * * * un minuto después de caer, escribiéndolo directo en el archivo de spool de cron —no por crontab -e—, así que ni siquiera queda la línea de siempre en el registro del sistema. Hay que abrir el spool.

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 la primera explotación confirmada 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 el calendario: Adobe tenía su próximo lanzamiento de seguridad programado para el 8 de septiembre —lo decía Sansec y lo confirmó BleepingComputer, que le preguntó puntualmente si el arreglo entraba ahí—. No esperó: publicó el 7 a las 20:20 UTC lo que Sansec describe como un «emergency hotfix», que es lo que suele hacer un fabricante cuando el fallo ya se está explotando.

🔄 Actualización del 7 de septiembre: el chequeo de ayer ya no alcanza

Sansec reescribió su informe tres veces el 7 de septiembre, y no fue para agregar color: cambió lo que hay que buscar. Si revisaste tu servidor con la lista original y te dio limpio, ese resultado ya no significa lo mismo. Lo que cambió, en orden de cuánto te rompe la revisión de ayer:

• El implante se cambió el nombre dos veces. A [kworker/u:8:0] se le sumaron fc-cache (6 de septiembre) y chronyd (el 7). Un grep armado con el nombre viejo no encuentra ninguna de las dos nuevas.
• El crontab dejó de ser el chequeo de treinta segundos, y ésta es la que más gente va a pasar por alto, porque era lo primero que todo el mundo miraba. La variante chronyd a veces se relanza sola sin agendar nada —o sea que un crontab vacío no prueba que estés limpio— y a veces sí agenda, pero escribiendo directo en el archivo de spool, que es donde Sansec pide mirar y no solo en la salida de crontab -l.
• Apareció un segundo atacante, sin relación con el primero, que entra por el mismo agujero y deja un web shell en PHP dentro de la carpeta de imágenes. Es un archivo, no un proceso: sacar el bicho de la memoria no lo toca.

Todo eso está incorporado abajo, en los chequeos y en la tabla de indicadores. La cronología de arriba también quedó ampliada con los hitos del 6 y el 7.

🆕 El parche: qué publicó Adobe, cómo se aplica y qué hay que rotar

El 7 de septiembre a las 20:20 UTC —el sello horario es de Sansec: el boletín de Adobe solo trae la fecha, y su índice general de boletines lo fecha ese mismo día— Adobe publicó el boletín APSB26-146, con prioridad 1, la más alta de su escala. Ahí el fallo dejó de ser anónimo: es CVE-2026-75650, puntuado CVSS 10.0, y el propio Adobe escribe en el boletín: «Adobe is aware of CVE-2026-75650 being exploited in the wild» (traducción del inglés: «Adobe sabe que CVE-2026-75650 se está explotando en el mundo real»).

Un detalle por si vas a chequearlo vos. Adobe tiene dos índices y al principio no se actualizaron juntos: el 8 de septiembre el general ya listaba el APSB26-146, pero el índice específico de Adobe Commerce —el que uno iría a mirar— seguía mostrando a las 11:26 UTC el APSB26-92 del 11 de agosto como el más nuevo. Al 13 de septiembre los dos lo listan, pero en el de Commerce el primero de la lista no es el APSB26-146 sino el APSB26-138, el boletín programado del 8 de septiembre, con prioridad 2 y otros ocho CVE sin explotación conocida, según Adobe. No reemplaza al hotfix: lo explicamos en el párrafo que sigue.

No es una versión nueva, es un hotfix. Se descarga desde repo.magento.com y se aplica como parche de composer. La nota de Adobe, en su versión actualizada el 11 de septiembre, trae una tabla con siete archivos —entre ellos el VULN-39341-composer-patches.zip del primer día— y a qué versiones corresponde cada uno; Adobe publicó las instrucciones en una nota de su base de conocimiento titulada, sin eufemismos, «Urgent Action Required». Para confirmar que quedó aplicado, el chequeo es vendor/bin/magento-patches -n status filtrando por 39341 — lo publican tanto Sansec como Adobe, con dos condiciones que Adobe agrega y conviene saber antes de teclearlo: requiere tener instalada la Quality Patches Tool, y Adobe lo documenta para clientes de Commerce on Cloud. Y va aparte del parche de septiembre. El APSB26-138 corrige otros fallos con un parche que el boletín presenta como versiones -2026-sep, pero que Adobe entrega solo como archivos de parche aislado, sin paquetes de Composer (a diferencia del hotfix, que sí se aplica como parche de composer); el boletín pide aplicar el hotfix además de sus propias actualizaciones, y las notas de ese boletín lo confirman: el parche de septiembre no incluye el hotfix, y da igual si lo aplicás antes o después.

La mitad que se saltea todo el mundo: rotar claves. Adobe no pide solo parchear. Pide, textual, aplicar el parche «and rotate your encryption keys» (traducción del inglés: «y rotar sus claves de cifrado»). Y la lista es de Adobe, en su propia base de conocimiento, no de un tercero: hay que rotar la clave de cifrado y todas las credenciales que esa clave protegía —contraseñas de administrador, tokens de integración REST/SOAP/GraphQL, secretos de cliente OAuth, credenciales de la pasarela de pago del lado del proveedor (Stripe, Braintree, Adyen, PayPal), credenciales de base de datos y de Fastly (estas, por ticket de soporte), claves SSH y de despliegue y credenciales de cuentas de servicio, y claves de API de extensiones de envío, impuestos y terceros—. La advertencia que vale por sí sola también es de Adobe: hay que rotarlas en el origen, no solo dentro de Magento, porque rotar la clave de cifrado por su cuenta no invalida las credenciales que ya pudieron quedar expuestas.

Y el orden no es decorativo. Adobe publica la rotación como una secuencia, y hay un paso que si te lo saltás te rompe la tienda: apagar el cron antes de tocar la clave. La secuencia es aplicar el hotfix → entrar en modo mantenimiento → desactivar la ejecución de cron (en Commerce on Cloud, vendor/bin/ece-tools cron:disable) → rotar la clave de cifrado → rotar los siete grupos de credenciales → limpiar la caché → volver a activar el cron → salir de mantenimiento → y, solo en Commerce on Cloud, volver a desplegar para que tomen las credenciales nuevas de base de datos («Redeploy to apply new database credentials»). Rotar la clave con el cron corriendo es exactamente cómo se rompe una tienda en producción un martes a la noche.

Qué versiones cubre, y qué cambió en la compatibilidad. Son dos listas distintas. Afectadas, según el boletín: Adobe Commerce de la rama 2.4.4 a la 2.4.9 y Magento Open Source de la 2.4.6 a la 2.4.9, en ambos casos 2.4.9-2026-aug y anteriores, más Adobe Commerce B2B de la 1.3.3 a la 1.5.3, en todas las plataformas. Que el boletín no nombre versiones más viejas no quiere decir que estén a salvo: Sansec aclara que para las ramas 2.2 y 2.3 y para las 2.4.0 a 2.4.3, que están fuera de soporte, Adobe no publica nada. Con archivo de hotfix, según la nota de Adobe: esa nota cambió después de publicada. El 8 de septiembre advertía que solo se había probado contra las versiones -2026-aug y que en otras versiones soportadas podía funcionar, pero sin verificación oficial. Desde su actualización del 11 de septiembre, esa advertencia ya no está: ahora dice que el hotfix «is now compatible with all the Adobe Commerce and Magento Open Source versions between 2.4.4 – 2.4.7» (traducción del inglés: «ahora es compatible con todas las versiones de Adobe Commerce y Magento Open Source entre la 2.4.4 y la 2.4.7») y remite a la tabla para bajar el archivo que corresponde a tu versión. Esa tabla tiene filas desde la 2.4.4 hasta la 2.4.8-p5, más las versiones que Adobe rotula -2026-jul y -2026-aug. Dos bordes que conviene mirar: la compatibilidad declarada incluye a Magento Open Source 2.4.4 y 2.4.5, que el boletín no lista como afectadas, y la 2.4.9 a secas no tiene fila: de esa rama solo aparecen la 2.4.9-2026-jul y la 2.4.9-2026-aug. Si el 8 te frenó esa advertencia, volvé a mirar la tabla; si tu versión no figura, acá están las opciones.

Y el parche no te dice si ya entraron. Por eso el orden de esta nota es parchear hoy y revisar igual. La primera víctima confirmada tenía el nivel de parche al día, y Sansec agrega que su bloqueo frenó una sonda contra una tienda 2.4.7-p10 el 7 de septiembre — o sea que el nivel de parche vigente antes del 7 de septiembre no era defensa, sencillamente porque el parche para este fallo todavía no existía. Si tu tienda estuvo publicada en algún momento desde el 4 de septiembre sin el hotfix, parchear cierra la puerta pero no revisa la casa. Y para revisar logs y correos, mirá también agosto (por qué).

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.

¿No tenés consola? Buena parte de las tiendas Magento de la región vive en hosting administrado sin acceso SSH, y estos chequeos no se pueden correr desde el panel. Si es tu caso, no los saltees: mandale esta sección a tu proveedor y pedile puntualmente tres cosas —la lista de procesos del usuario del sitio filtrada por kworker, fc-cache y chronyd —y, por lo que sumó Sansec el 14 de septiembre, también por kstrp, ksmd y apache@notty—; el crontab de esa cuenta leído del archivo de spool, que no es lo mismo que la salida de crontab -l; y si hay algún archivo .php bajo pub/media, buscado con find -L pub/media -type f -name '*.php', que es la forma que Sansec publica ahora—. Son tres respuestas cortas y no requieren que el proveedor entienda la vulnerabilidad.

• 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.
• Los tres nombres, no uno — y ojo, que la regla de arriba se da vuelta. El chequeo de procesos que publica hoy Sansec busca las tres variantes juntas: kworker, fc-cache y chronyd. Pero el truco del punto anterior —»si está entre corchetes y no es de root, es el implante»— solo sirve para la primera: fc-cache es un programa real que corre con el usuario del sitio, y chronyd es el servicio de hora legítimo de casi cualquier Linux. Van a aparecer procesos con esos nombres que están perfectamente bien. Lo que separa al impostor del legítimo son tres cosas concretas: la ruta desde la que corre (/tmp/.chrony-<8hex>/chronyd o ~/.cache/fontconfig/fc-cache no son las del sistema), el proceso padre —en el host que Sansec documentó primero, el implante colgaba del PID 1, pero ojo: eso está observado en un caso y no publicado como regla, así que la ruta es el indicador firme y el padre es apenas una pista— y el patrón de red descrito más arriba: nueve paquetes cada 60 segundos donde un cliente de hora real manda uno. Ante un proceso sospechoso, mirá de dónde salió el ejecutable antes de alarmarte.
• Persistencia y archivos sueltos. Buscar entradas de cron con gvfsd o .kw_, y los directorios ~/.local/share/.gvfsd/, /tmp/.kw_* y /tmp/.gvfsd-*. A esa lista Sansec le sumó las rutas de las variantes nuevas: ~/.cache/fontconfig/fc-cache, /tmp/.fc-*/fc-cache, /tmp/fc-cache, /tmp/.chrony-*/chronyd, /tmp/.cache_* y el archivo de bloqueo ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock. Y ya son tres cadenas de cron, no una: al */5 * * * * original se le sumaron el 13,43 * * * * de la variante del 6 de septiembre, apuntando a fc-cache, y el 57,27 * * * * de la del 7, apuntando a /tmp/.chrony-<8hex>/chronyd. Esta última hay que leerla del archivo de spool de cron: se escribe directo ahí, sin pasar por crontab -e, así que el registro del sistema no deja rastro de que alguien la agendó.
• Un intento fallido que queda escrito, y es la señal más barata de todas. En los servidores donde el usuario del sitio no puede escribir un crontab, el implante lo intenta igual, una vez por minuto, y cada intento queda registrado como crontab[<pid>]: (www-data) AUTH (crontab command not allowed). En la tienda que lo reportó, ese usuario estaba en /etc/cron.deny: la persistencia nunca funcionó, quedaron miles de líneas en el syslog y la primera de ellas fechó la infección más de un día antes de que alguien notara el proceso. Buscala en tus registros de autenticación.
• PHP donde no debería haber ninguno. El segundo atacante escribe su web shell dentro de la caché de imágenes de productos, en pub/media/catalog/product/cache/, donde los nombres de carpeta son hashes y un archivo de más pasa desapercibido. Bajo pub/media no debería existir ningún .php: un find -L pub/media -type f -name '*.php' que devuelva algo ya es hallazgo. Es la forma que Sansec publica desde su actualización vista el 17 de septiembre; la anterior no llevaba -L ni -type f.
• 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.

Cuatro 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.
• Y el crontab hay que mirarlo distinto. Es la advertencia más nueva y la que más gente va a pasar por alto, porque revisar el cron era el chequeo rápido que todo el mundo hacía primero. Ahora falla por los dos lados: la variante chronyd puede relanzarse sola sin agendar nada —así que un crontab vacío no es evidencia de que el servidor esté limpio—, y cuando sí agenda, Sansec avisa que escribe directo en el archivo de spool y que hay que abrir ese archivo en vez de confiar en lo que devuelve crontab -l.

Y una señal más, para el caso en que el ataque casi falla: un comerciante reportó un intento que rebotó contra el almacenamiento de sesiones y, ocho segundos después, un segundo intento del mismo operador que sí entró, usando como vía alternativa un archivo subido a través de las opciones personalizadas de Magento. Un rebote seguido de un acierto a los segundos, desde el mismo origen, es de las cosas que conviene mirar dos veces en el log de acceso — eso lo decimos nosotros, y abajo está por qué.

Una precisión de rastro, porque esta nota se apoya en un informe que se reescribe solo: en la versión del 7 de septiembre de las 13:05 UTC, Sansec calificaba ese patrón como digno de alerta y agregaba que el archivo de respaldo lo borra el propio cron de Magento, así que para cuando alguien mira ya no está. En la versión de las 13:29 esas dos frases no están, y por eso acá figuran datadas y no en presente: la recomendación de mirar ese patrón la sostenemos nosotros. El hecho —el rebote, los ocho segundos y la vía alternativa— sigue publicado.

Indicadores de compromiso, al 17 de septiembre

Esta tabla creció con cada relectura desde que publicamos esta nota el 6 de septiembre, y conviene leerla sabiendo eso: no es una lista cerrada, es la foto de un ataque que se está moviendo. Lo que Sansec sumó el 14 de septiembre va en una tabla aparte, más abajo, y lo que vimos el 17, en otra, para que esta quede como la foto del 13, con una sola salvedad fechada en la fila de los correos. Las filas marcadas como nuevas no existían en la versión original del informe. Última actualización de esta tabla: 13 de septiembre, sobre la lista completa del informe que Sansec da por actualizado ese día a las 10:00 UTC: de ahí salen dos direcciones de origen y un dominio de exfiltración que esta tabla no tenía, marcados abajo. La anterior, del 8 de septiembre a las 11:30 UTC, había sumado las filas de la sonda de reconocimiento que Sansec publicó el 7 a las 20:45, junto con el parche; en esa misma relectura del 8 entraron una tercera línea de cron y la advertencia de mirar el archivo de spool, que Sansec había sumado —el hash del binario chronyd no va en esta tabla porque sin un escáner no le sirve a nadie, está en el informe—, y filas que el informe ya traía y esta tabla venía sin recoger.

La fila del web shell merece un párrafo aparte, porque no es una variante más del mismo bicho: es otra gente. Sansec analizó el 7 de septiembre un dropper de PHP de 485 bytes que, en sus palabras, no comparte nada con el implante salvo las víctimas, y clasifica al conjunto como herramienta sin relación con la anterior. Entró por la misma puerta: StyleSmuggler. La consecuencia práctica es la que importa: matar el proceso de fondo no te deja limpio, porque esto es un archivo, no un proceso.

Sobre las filas de direcciones de origen, un aviso de tamaño: Disrex contó 26 direcciones de origen distintas en sus dos tiendas y calculó que bloquear 88.216.72[.]181 —que al momento de publicar esta nota era la única dirección de origen del aviso de Sansec— habría frenado menos de un cuarto del tráfico que vio. Al 13 de septiembre Sansec ya listaba seis direcciones de origen más, y el 14 sumó otra tanda, con un rango entero incluido (va en la tabla de abajo). Y eso no debilita el aviso: lo confirma. Las listas de IOC sirven para encontrar, no para blindar, y ésta no deja de crecer.

Agregados por Sansec el 14 de septiembre. Sale de la lista que Sansec actualizó ese día, con las herramientas de la tienda comprometida el 9 de septiembre. Dejamos afuera los hashes y las marcas más técnicas, como en la tabla de arriba, y la lista completa está en el informe de Sansec. Una advertencia antes de la tabla: en esa tienda, Sansec encontró los archivos en el /tmp privado de PHP-FPM (la ruta va en la tabla), que según el informe es donde de verdad está el /tmp de PHP. Por esa misma razón, las rutas de /tmp de la tabla anterior conviene buscarlas también ahí; eso último lo decimos nosotros.

Agregados por Sansec y vistos el 17 de septiembre. Salen de la lista del informe tal como la releímos ese día. Igual que en las tablas anteriores, la lista completa está en el informe de Sansec; acá van las que se revisan en los logs y en la casilla de correo de la tienda.

Qué más podés hacer además de parchear

El arreglo del fabricante ya existe y es lo primero. Lo que sigue son capas que se escribieron cuando no lo había, y siguen sirviendo en tres casos concretos: mientras revisás el servidor; si tu versión no figura en la tabla de Adobe —cualquier 2.2, 2.3 o 2.4.0 a 2.4.3, y también la 2.4.9 a secas—; y si por algún motivo todavía no podés aplicar el hotfix. Ninguna reemplaza al parche oficial, que para las versiones de la tabla está a un composer de distancia.

Antes de la tabla, una que Sansec sumó el 7 de septiembre y que conviene leer con atención si tu instinto fue mover las sesiones: pasar el almacenamiento de sesiones a Redis o a la base de datos no frena el ataque. Cuando esa vía falla, el atacante tiene otra —un archivo subido por las opciones personalizadas de Magento— y la usó ocho segundos después. Que esta nota te mande a vaciar el almacenamiento de sesiones es una medida de limpieza post-incidente, no un blindaje: no lo confundas con una defensa.

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 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.

La primera aclaración que obligan a hacer las variantes nuevas es sobre el paso de la persistencia, y es la que más caro sale saltear. Si el proceso que encontraste es el chronyd del 7 de septiembre, igual tenés que buscarla, y en el lugar difícil: Sansec corrigió su informe esa misma tarde para decir que la persistencia varía entre hosts. En la tienda donde lo vio primero no había entrada de cron y el proceso colgaba del PID 1, pero otro comerciante reportó el mismo binario sí agendado, un minuto después de caer, con la línea 57,27 * * * * /tmp/.chrony-<8hex>/chronyd. Está escrita directo en el archivo de spool de cron en vez de pasar por crontab -e, así que no aparece en el registro del sistema: hay que abrir el spool y no confiar en la salida de crontab -l. Matar el proceso sin mirar ahí te deja el implante volviendo a los :27 y :57 de cada hora.

La segunda es sobre «buscar otras puertas traseras», que dejó de ser una precaución de manual. En algunas de estas tiendas hay un web shell en PHP de otro atacante: es un archivo, no un proceso, así que sobrevive intacto a cualquier limpieza hecha solo sobre la memoria, y en el orden clásico quedaría para el final. Si aparece, va antes.

Y después de todo eso, esperar y volver a chequear, porque el bicho restauraba su persistencia casi al instante. Cuánto esperar cambió con las variantes: contra la primera alcanzaba con pasar los cinco minutos de su cron, la del 6 de septiembre revive dos veces por hora y la del 7 puede no agendar nada o esconder su línea en el spool. O sea que hay que volver a mirar más de una vez y a distintas horas, no una sola pasada rápida.

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. Y conviene no estirarlo: desde el 14 de septiembre, la lista de indicadores de Sansec incluye un skimmer guardado en la base de datos de otra tienda —la comprometida el 9—, anotado entre sus puertas traseras secundarias. Sansec no dice por dónde entró ese skimmer ni lo atribuye a StyleSmuggler, así que acá tampoco. Y dos límites más, que el material nuevo obliga a poner: esa lectura tranquilizadora es sobre el implante —del web shell del segundo atacante nadie publicó todavía evaluación de impacto, y de la tienda del 9 de septiembre tampoco—, y la afirmación de Sansec sobre la puerta trasera sigue en pie al 14 de septiembre, pero es una foto de un caso que se mueve todos los días.

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. Resuelto el 7 de septiembre: el boletín las lista explícitamente —Adobe Commerce 2.4.4 a 2.4.9 y Adobe Commerce B2B 1.3.3 a 1.5.3, plataforma «All»—, y la nota de la base de conocimiento incluye un paso de verificación específico para los clientes de Adobe Commerce on Cloud. Sí están afectadas.
• 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.
• Cuándo llega el arreglo, y si el boletín del 8 de septiembre lo cubre. Resuelto el 7 de septiembre: Adobe se adelantó al boletín programado y publicó el APSB26-146 esa noche, con CVE, puntaje y hotfix. Está acá.
• Si el hotfix funciona en las versiones más viejas de cada rama. Resuelto el 11 de septiembre, con un borde: Adobe sacó de su nota la advertencia de que solo lo había probado contra las -2026-aug y publica una tabla de archivos de parche por versión, de la 2.4.4 a la 2.4.8-p5 más las rotuladas -2026-jul y -2026-aug; la 2.4.9 a secas queda afuera (ítem siguiente). Está acá.
• Qué hacer si tu versión no está en la tabla. Para 2.2, 2.3 y 2.4.0 a 2.4.3 no hay archivo de Adobe, y la vía que menciona Sansec es un backport de terceros que no revisó (detalle). Y para la 2.4.9 a secas, que no tiene fila, la nota del hotfix no dice qué archivo le toca.
• Quién es el segundo atacante y si llegó a usar su web shell. Sansec lo describe pero no lo atribuye, y no publicó evaluación de impacto sobre ese acceso.
• Qué pasó en la tienda comprometida el 9 de septiembre. Sansec publica las herramientas y el skimmer, pero no por dónde entró ese skimmer, quién está detrás ni si se robaron datos.
• Cómo sobrevive a un reinicio la variante chronyd cuando NO agenda cron. En la tienda donde sí agenda, el mecanismo está publicado y es la línea 57,27 del spool. En la otra —la que cuelga del PID 1 sin agendar nada— Sansec no publicó por qué mecanismo vuelve. Ese hueco sigue abierto y conviene decirlo: ahí no sabemos qué hay que sacar para que no reaparezca.
• 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.

Antes del boletín: el reconocimiento privado del 7 de septiembre

Lo que se sabía en las horas previas al parche.

Apareció la primera señal de vida del fabricante desde la primera explotación confirmada, el 4 de septiembre. Sansec lo sumó a su informe en una reescritura del 7 de septiembre que llevaba sello de las 13:29 UTC, y bajo el rótulo «Update» escribió dos frases que citamos enteras, en el inglés original, porque todo el peso está en las palabras exactas: «Adobe Enterprise Support confirmed on Sept 7th that they were working on a patch. No ETA yet». Traducido: el soporte empresarial de Adobe confirmó el 7 de septiembre que están trabajando en un parche, y no hay fecha estimada.

Esa frase ya no está en el informe de Sansec, y conviene decirlo. Cuando salió el parche, Sansec reescribió el artículo —el sello vivo pasó a ser el de las 20:45 UTC del 7 de septiembre— y en esa pasada borró el párrafo del reconocimiento privado. La citamos de nuestra propia lectura fechada de las 17:21 UTC, que es la que teníamos abierta cuando escribimos esto; si hacés clic hoy en el informe no la vas a encontrar. La dejamos porque explica el estado de la información en esas horas, no porque siga publicada.

Quién dice qué, que acá es la mitad del asunto. Eso no fue un comunicado de Adobe: fue Sansec contando lo que le contestó el soporte empresarial del fabricante. En ese momento Adobe no había publicado nada propio. Releímos su índice oficial de boletines a las 17:25 UTC y en la sección de Commerce el más nuevo seguía siendo el APSB26-92 del 11 de agosto. BleepingComputer, que levantó el caso el mismo día, dijo haberle preguntado a Adobe si el arreglo entraba en el boletín del 8 de septiembre y que la empresa no le había respondido. Tres horas más tarde, el boletín estaba publicado.

Qué cambió después. Ese «sin fecha estimada» duró menos de lo que sugería: el boletín salió esa misma noche, unas horas después de que Sansec publicara el reconocimiento. Queda como recordatorio de lo poco que se puede deducir de un «estamos trabajando en eso» — en este caso el fabricante llegó antes de lo que su propia respuesta dejaba entrever, y podría haber sido al revés.

¿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. Y eso no es una interpretación nuestra: el vector CVSS que publicó Adobe lleva S:C —scope changed, alcance modificado—, que es exactamente la manera formal de decir que el daño se sale del componente vulnerable. Es también lo que empuja el puntaje a 10.0. 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, con las dos salvedades que sumó Sansec el 14 de septiembre.

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

Revisé mi servidor con la primera lista de indicadores y me dio limpio. ¿Alcanza?

No, y conviene volver a pasar. Entre el 6 y el 7 de septiembre cambiaron tres cosas que rompen la revisión anterior: el implante se cambió el nombre dos veces —a fc-cache primero y a chronyd después—, así que buscar solo [kworker/u:8:0] ya no encuentra nada; la última variante a veces no deja entrada de cron y a veces la esconde en el archivo de spool, con lo cual un crontab vacío dejó de ser prueba de nada y la línea, cuando existe, hay que buscarla en el archivo de spool; y apareció un segundo atacante que deja un archivo PHP bajo pub/media, que ninguna búsqueda de procesos va a mostrar. La lista actualizada está en los chequeos y en la tabla de indicadores. Y si buscaste PHP en la carpeta de medios con find pub/media -name '*.php', repetilo con la forma que Sansec publica ahora, find -L pub/media -type f -name '*.php'; las huellas que sumó después están en la tabla del 14 y en la del 17.

¿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.

¿Adobe sacó el parche?

Sí. El 7 de septiembre a las 20:20 UTC publicó el boletín APSB26-146 con prioridad 1, un día antes del boletín que tenía programado. El arreglo es un hotfix —VULN-39341—, no una versión nueva, y viene con un pedido explícito de rotar la clave de cifrado y todas las credenciales que protegía. Cómo se aplica, acá. Antes de eso, lo único que se le conocía al fabricante era un reconocimiento privado contado por Sansec.

¿Tiene número de CVE?

Sí, desde el 7 de septiembre: es CVE-2026-75650, con puntaje CVSS 10.0 —el máximo— y categoría de ejecución de código arbitrario sin autenticación. Y ya figura en el catálogo de vulnerabilidades explotadas conocidas de CISA: la versión 2026.09.11, con 1.709 entradas, lo lista con fecha de alta el 8 de septiembre. Actualizado el 13 de septiembre: hasta ese día esta respuesta decía que no figuraba, porque la versión que habíamos consultado el 8, la 2026.09.04 con 1.695 entradas, todavía tenía como entrada más nueva el zero-day de Chrome que cubrimos el 3 de septiembre. La ficha le pone como fecha límite («Due Date») el 11 de septiembre y remite a la directiva BOD 26-04, que obliga a las agencias civiles del poder ejecutivo federal de EE.UU. a remediar lo que CISA suma a ese catálogo dentro de los plazos que fija la propia CISA. Esa directiva no alcanza a una tienda privada, pero sirve de vara: entre el alta y la fecha límite hubo tres días, y ya pasaron. Y la ficha no pide solo mitigar: remite también al triage forense de CISA, que la directiva describe como revisar el equipo para evaluar si ya fue comprometido. En la misma ficha, el uso en campañas de ransomware figura como «Unknown», o sea desconocido.

¿Esto se parece a algo que ya haya pasado?

Al caso de Telerik UI que contamos el 7 de septiembre, con una diferencia que es justo la que importa. Allá el parche estaba desde julio y el problema era que nadie lo había instalado; acá el parche salió el 7 de septiembre, tres días después de la primera explotación confirmada, y el problema es llegar antes que los atacantes. El patrón de fondo es el mismo —ejecución de código sin autenticar en un servidor expuesto a internet— y la lección también: en este tipo de fallas, el día que sale el arreglo empieza la carrera, no termina.

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