StyleSmuggler, el fallo de 10/10 en Magento y Adobe Commerce, dejó puertas traseras antes de que existiera el parche

Del 4 al 7 de septiembre de 2026 hubo tres días en los que cualquier tienda con Magento o Adobe Commerce expuesta en internet pudo ser tomada por un atacante sin necesitar contraseña ni clic de nadie. El fallo se llama CVE-2026-75650, lo bautizó Sansec como "StyleSmuggler" y tiene la calificación máxima de severidad: CVSS 10.0. Adobe liberó el parche de emergencia el 7 de septiembre, pero instalarlo hoy no borra lo que un atacante ya haya dejado adentro durante esos tres días.

Esa es la parte que importa para quien decide presupuesto: "ya actualizamos" no es lo mismo que "ya estamos limpios". Si tu tienda estuvo en línea y sin parchar entre el 4 y el 7 de septiembre, el parche cierra la puerta por la que entraron, pero no saca a quien ya entró.

Cómo funcionó el ataque

La investigación técnica de Sansec, la empresa que descubrió la explotación activa, describe una cadena en dos pasos. Un atacante sin autenticar envía una petición al endpoint de GraphQL de Magento con código PHP malicioso escondido dentro de un encabezado o parámetro HTTP. Magento no reconoce ese valor, así que lo registra tal cual en un archivo de log del servidor, sin darse cuenta de que acaba de guardar código ejecutable. Ese código queda dormido hasta que el sistema genera un correo de "Payment Transaction Failed Reminder" (recordatorio de pago fallido), momento en el que la plantilla de ese correo procesa el valor guardado y lo ejecuta. Nadie tiene que abrir el correo. Con que el sistema lo genere internamente, basta.

El fallo afecta Adobe Commerce de la versión 2.4.4 a la 2.4.9 y Magento Open Source de la versión 2.4.6 a la 2.4.9, y Adobe Commerce B2B de la 1.3.3 a la 1.5.3. Adobe publicó el boletín de emergencia APSB26-146 el 7 de septiembre con la prioridad más alta de su escala, y el parche se distribuye como hotfix (VULN-39341), no como versión completa: hay que descargarlo aparte desde repo.magento.com y aplicarlo como parche de composer.

CISA, la agencia de ciberseguridad de Estados Unidos, sumó la falla a su catálogo de vulnerabilidades explotadas el 8 de septiembre con plazo de remediación al 11 de septiembre para agencias federales, la misma urgencia que ya vimos con el firewall de Cisco que se usó para instalar el ransomware Qilin o con la falla de GitLab autoalojado con el mismo CVSS 10.0.

Qué dejaron adentro

Según el reporte de BleepingComputer, los atacantes no se limitaron a robar datos en el momento: instalaron un implante persistente. Se trata de un binario compilado en Rust que corre como proceso en segundo plano y se camufla bajo nombres de procesos legítimos de Linux. Entre el 4 y el 7 de septiembre esa máscara cambió tres veces: primero como [kworker/u:8:0] (imitando un hilo del kernel), después como fc-cache (la utilidad de caché de fuentes), y finalmente como chronyd, el demonio real de sincronización de hora.

Ese último disfraz explica el detalle que más le importa a quien revisa tráfico de red: el implante genera su comunicación con el servidor de comando y control simulando tráfico NTP legítimo por el puerto UDP 123. Envía ráfagas de nueve paquetes de 48 bytes cada uno, separados por unos 10 milisegundos, cada 60 segundos, y los marca como si fueran respuestas de un servidor NTP, algo que un cliente real de sincronización de hora nunca envía. Es tráfico diseñado para pasar desapercibido en herramientas de monitoreo de red que dan por buena cualquier cosa que suene a "sincronización de reloj". Además del implante en Rust, se detectó un segundo componente: un dropper en PHP capaz de escribir web shells para ejecutar código PHP arbitrario más adelante, sin depender de que la vulnerabilidad original siga abierta.

Por qué el parche no es el cierre del caso

Aquí está el punto que varias guías de proveedores de Magento remarcan por separado: aplicar VULN-39341 corrige la vulnerabilidad de inyección, pero no toca nada de lo que un atacante haya instalado antes de ese momento. Ni el proceso disfrazado, ni el cron que lo reinicia, ni los web shells en PHP, ni las credenciales que el atacante haya podido leer mientras tuvo acceso.

Por eso Adobe pide, además de aplicar el hotfix, rotar la clave de cifrado de Magento y todo lo que esa clave protege: contraseñas de administrador, tokens de integración de API (REST, SOAP y GraphQL), secretos de cliente OAuth, credenciales de las pasarelas de pago a nivel del proveedor (Stripe, PayPal, Braintree, Adyen o la que uses), credenciales de base de datos y llaves SSH. Rotar la clave sin rotar lo que protege no sirve de nada: invalida hacia adelante, no lo que el atacante ya copió.

El procedimiento recomendado es: activar modo mantenimiento, pausar el cron, aplicar el hotfix, rotar todos los secretos de la lista, vaciar caché, reactivar el cron y salir de mantenimiento. Y antes de dar el tema por cerrado, revisar si ya hay algo instalado.

Qué revisar en tu operación, en este orden

1. Procesos en el servidor. Busca procesos llamados kworker, fc-cache o chronyd que no correspondan a los procesos legítimos del sistema, en particular si corren bajo el usuario de la aplicación web en lugar del usuario de sistema, o desde una ruta que no es la habitual del binario real.
2. Tráfico de salida por el puerto 123. Si tu monitoreo de red lo permite, compara los destinos del tráfico NTP contra tu lista real de servidores de tiempo configurados. Tráfico UDP 123 hacia un destino que no está en esa lista es la señal más concreta que dejó este ataque.
3. Entradas de cron que nadie reconoce. Revisa el crontab del usuario de la aplicación y del sistema completo, no solo el que administra Magento.
4. Archivos PHP donde no debería haber ninguno. Directorios de medios o de subida de archivos (pub/media, por ejemplo) no deberían poder ejecutar PHP. Si encuentras un .php ahí, es una bandera roja.
5. Picos de correos de pago fallido en tus logs, alrededor de las fechas del 4 al 7 de septiembre, como rastro de los intentos de explotación.

Si algo de esto aparece, el trabajo ya no es "aplicar el parche": es respuesta a incidente completa, con rotación de credenciales y, según lo que se encuentre, reconstrucción del servidor desde una imagen limpia.

Dónde esto no aplica

Si tu tienda corre en una plataforma como Shopify, VTEX o cualquier SaaS donde no administras el servidor ni el código de plantillas, esta falla específica no te toca: el problema vive en cómo Magento renderiza sus propias plantillas de correo, no en el catálogo o el checkout en sí. Tampoco aplica si migraste por completo fuera de Magento antes de 2026.

Pero si tu empresa contrata una agencia o un proveedor de hosting que administra el Magento por ti, la respuesta obvia (preguntar "¿ya está parchado?" y quedarte tranquilo con un "sí") es la equivocada. La pregunta correcta es si además de aplicar VULN-39341 rotaron las credenciales y revisaron procesos, cron y archivos en busca del implante. Un "ya parcheamos" sin esa segunda parte deja exactamente el mismo riesgo que tenías antes de preguntar.

En México hay al menos 501 tiendas activas con Magento según el rastreo de storeleads.app, y el Buen Fin 2026 corre del 13 al 17 de noviembre, después de que la edición 2025 moviera 219 mil millones de pesos entre unos 216 mil negocios. Una tienda con un backdoor sin detectar llegando a esa ventana de tráfico alto no es un escenario hipotético: es el momento exacto en el que un atacante que ya tiene acceso decide usarlo, justo cuando hay más transacciones de pago pasando por el sistema y más ruido de fondo para esconderse. Antes de esa fecha conviene también revisar si tu plataforma de venta en línea aguanta cinco días de tráfico sostenido, porque un pico de tráfico legítimo es mal momento para descubrir que también tienes un huésped no invitado.

Ese tipo de revisión (procesos, tráfico, archivos, credenciales, todo a la vez y no uno por uno cuando ya es tarde) es justo lo que cubre dar soporte continuo y operar el hosting de una plataforma en vez de dejarla sola después de la entrega; es el mismo terreno donde ya hemos operado el hosting de un producto de ciberseguridad con pipelines de escaneo de vulnerabilidades. Si administras un Magento que estuvo expuesto esos tres días y quieres una segunda revisión antes de asumir que "ya quedó", una revisión de lo que dejó atrás una vulnerabilidad ya parchada es distinto a instalar un hotfix y dar vuelta a la página.

Fuentes

• Sansec: StyleSmuggler, Magento and Adobe Commerce 0-day RCE (CVE-2026-75650)
• The Hacker News: Adobe Patches Magento Zero-Day Exploited to Deploy Rust Backdoor
• BleepingComputer: Adobe fixes critical Magento zero-day exploited to backdoor servers
• TechTimes: Adobe Patches Magento Zero-Day That Hacked Stores, All Patches Applied
• CISA: Known Exploited Vulnerabilities Catalog, CVE-2026-75650