Magento StyleSmuggler es un zero-day de Adobe Commerce y Magento Open Source explotado activamente. Adobe lo identifica como CVE-2026-75650, una vulnerabilidad crítica de ejecución de código sin autenticación con una puntuación CVSS de 10.0. Si gestionas una tienda afectada, aplica ahora el hotfix VULN-39341 de Adobe, rota las claves de cifrado y las credenciales, y luego busca mecanismos de persistencia. Aplicar el parche por sí solo puede cerrar la brecha, pero no eliminará una puerta trasera ya implantada.
Magento StyleSmuggler: la versión de emergencia
La intención de búsqueda aquí es operativa, no académica. Probablemente estás intentando responder rápidamente a tres preguntas: ¿estoy afectado?, ¿qué hago primero? y ¿cómo sé que la tienda está limpia?
Adobe publicó el boletín APSB26-146 el 7 de septiembre de 2026, identificando Magento StyleSmuggler como CVE-2026-75650. La vulnerabilidad está clasificada como CWE-1336, neutralización incorrecta en un motor de plantillas, y Adobe le asignó Prioridad 1 porque la explotación se está produciendo activamente contra comerciantes de Commerce.
Sansec informó de los primeros ataques el 4 de septiembre de 2026 y describió públicamente la campaña el 5 de septiembre. BleepingComputer, SecurityWeek y The Hacker News también informaron de explotación activa, y BleepingComputer y SecurityWeek dijeron que los atacantes desplegaron puertas traseras persistentes de Linux/Rust tras la intrusión.
No trates esto como un aviso normal de “aplicar el parche durante la próxima ventana”. Un fallo de ejecución de código del lado del servidor sin autenticación en una pila de comercio electrónico orientada a pagos es de lo peor que puede haber. Si tu proceso de pago está activo, tu ventana de riesgo está abierta.
¿Quién está afectado y qué versiones figuran en la lista?
Adobe dice que el problema afecta a Adobe Commerce, Adobe Commerce B2B y Magento Open Source en todas las plataformas. Su guía de la base de conocimiento del 9 de septiembre de 2026 enumera Adobe Commerce 2.4.9-2026-aug hasta 2.4.4-2026-aug y anteriores, además de las versiones correspondientes de Magento Open Source y B2B.
Para Magento Open Source, la lista de versiones afectadas de Adobe incluye 2.4.9, 2.4.8, 2.4.7 y 2.4.6-2026-aug y anteriores. Para Adobe Commerce B2B, incluye 1.5.3, 1.5.2, 1.4.2, 1.3.4 y 1.3.3-2026-aug y anteriores.
Un caso límite desagradable: Sansec informó de que la primera víctima conocida ejecutaba 2.4.6-p15 con los parches de julio y agosto de 2026 aplicados y un security:patch-status. En pocas palabras, estar “completamente parcheado” antes de APSB26-146 no protegió esa tienda.
| Artículo | Estado en 2026 | Por qué es importante |
|---|---|---|
| CVE | CVE-2026-75650 | Identificador de Adobe para StyleSmuggler |
| Gravedad | Puntuación CVSS 3.1 10.0 | Clasificación crítica máxima |
| Autenticación | Ninguno requerido | Los atacantes no necesitan una cuenta de administrador |
| Prioridad de Adobe | Prioridad 1 | Adobe espera una aplicación urgente del parche |
| Explotación observada | Desde el 4 de septiembre de 2026 | Los ataques reales precedieron al hotfix de Adobe |
| Corrección denominada por Adobe | Hotfix VULN-39341 | Se requiere un hotfix adecuado para la versión |
Sansec también afirma que reprodujo la cadena completa de explotación no autenticada en instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9. Esa afirmación procede de la investigación de Sansec, no del boletín de Adobe, pero es relevante desde el punto de vista operativo porque esas son ramas habituales sobre el terreno.
Cómo funciona el exploit, en lenguaje de operadores
Sansec afirma que Magento StyleSmuggler abusa del sistema de plantillas de Magento inyectando código PHP a través de las propiedades de styles . El código contaminado se ejecuta después a través de una ruta de correo electrónico de pago fallido, lo que explica una de las señales más extrañas que han notificado los defensores: aumentos inesperados en los correos electrónicos de Magento “Payment Transaction Failed Reminder”.
Ese detalle importa para la clasificación inicial. Una tienda puede parecer normal desde el frontend mientras la plantilla y la ruta de correo electrónico se están utilizando como vía de ejecución. Si tu única comprobación del estado es “¿los clientes pueden navegar y pagar?”, te estás perdiendo la parte que les importa a los atacantes.
Antes de que Adobe publicara el hotfix, Sansec, BleepingComputer y The Hacker News citaron la contención temporal mediante la desactivación de GraphQL cuando era posible. Después del 7 de septiembre de 2026, Adobe y Sansec cambiaron la recomendación: aplicar VULN-39341 en lugar de confiar solo en bloqueos o desactivaciones de funciones.
Hay un riesgo que merece más atención. Sansec afirma que mover las sesiones a Redis o al almacenamiento en base de datos no detiene el ataque, e informó de que un operador cambió a un archivo subido mediante opciones personalizadas de Magento después de que fracasara un intento relacionado con el almacenamiento de sesiones. En otras palabras, la vía del atacante puede adaptarse para sortear una mitigación limitada.
Si estás revisando una exposición más amplia, compáralo con otros eventos de parcheo de emergencia como el patrón de respuesta ante zero-day de PaperCut: el fallo habitual no es la falta de un parche, sino asumir que el parche también elimina al intruso.
Aplica la corrección de Adobe y luego inmoviliza las partes móviles
La secuencia de corrección de Adobe del 9 de septiembre de 2026 es específica. Aplica el hotfix VULN-39341 correspondiente a la versión, activa el modo de mantenimiento, desactiva la ejecución de cron, rota las claves de cifrado, rota todas las contraseñas de Admin, desactiva o regenera los tokens de integración de REST, SOAP y GraphQL, y rota los secretos de cliente de OAuth.
Sigue la secuencia con cuidado. Cron no es un detalle menor aquí porque Sansec observó persistencia a través de entradas de cron, incluida una fc-cache variante que se ejecuta dos veces por hora a las 13,43 * * * *. Si cron sigue ejecutándose mientras limpias, puede que estés compitiendo contra el implante en tu propio servidor.
- Identifica la versión exacta de Adobe Commerce, Commerce B2B o Magento Open Source y selecciona el hotfix VULN-39341 correspondiente de las indicaciones de Adobe.
- Pon la tienda en modo de mantenimiento durante el periodo de respuesta, especialmente si las credenciales de pago o de administración pueden estar expuestas.
- Desactiva la ejecución de cron antes de rotar secretos o eliminar tareas sospechosas.
- Aplica el hotfix y verifica el estado del parche con las herramientas que normalmente usa tu despliegue.
- Rota la clave de cifrado de Commerce, todas las contraseñas de Admin, los tokens de API, los secretos de cliente de OAuth y las credenciales de pago de nivel superior o de terceros.
- Analiza el host, el árbol de la aplicación, los informes y los crontabs en busca de indicadores antes de volver a activar las tareas programadas.
Aquí está el cálculo que muchos comerciantes evitan: incluso una pausa de emergencia de dos horas en el checkout puede salir más barata que una semana de pedidos contaminados. Si una tienda factura $120,000 al día, dos horas de inactividad suponen aproximadamente $10,000 de exposición en ventas brutas; un compromiso con credenciales de la pasarela de pago, la contratación de análisis forense, la gestión de contracargos y las notificaciones a clientes pueden superar eso rápidamente. Tus cifras serán distintas, pero las matemáticas respaldan una interrupción controlada frente a una limpieza a ciegas.
Para pensar en una limpieza específica de pagos, el consejo práctico de controles de pagos seguros online se aplica aquí: rota en el origen, no solo dentro de la aplicación de comercio electrónico que almacenó el secreto.
Búsqueda de puertas traseras después de Magento StyleSmuggler
La actualización de Sansec del 9 de septiembre es tajante: aplicar el parche cierra la vulnerabilidad, pero no limpia las tiendas ya comprometidas. Restaurar solo desde una copia de seguridad también puede pasar por alto la persistencia si el atacante plantó tareas de cron, binarios ocultos, plantillas modificadas o credenciales que todavía funcionan en otro lugar.
Empieza por los indicadores que publicó Sansec. Busca procesos o archivos sospechosos llamados [kworker/u:8:0], fc-cache, y chronyd cuando no coinciden con las rutas y el comportamiento que espera el sistema operativo. Compruebe si hay archivos o procesos en ~/.local/share/.gvfsd/, ~/.cache/fontconfig/fc-cache, /tmp/.kw_*, /tmp/.cache_*, /tmp/.gvfsd-*, /tmp/.fc-*/fc-cache, /tmp/fc-cache, y /tmp/.chrony-*/chronyd.
Los informes de Magento también merecen atención. Sansec recomienda comprobar si hay x_trace_ entradas en var/report/. Los aumentos inesperados en los correos electrónicos de recordatorio de pago fallido son otra pista, especialmente si comenzaron entre el 4 y el 7 de septiembre de 2026.
La telemetría de red puede ayudar, pero no dependa de una única IP. Sansec informó de una IP de mando y control como 99.84.67.186, y dijo que una variante posterior fc-cache usaba tráfico NTP-like UDP/123 hacia dominios que incluyen ntp.timesync.to, ntp.timesysnc.net, ntp.synctime.to, y ntp.syncstime.to, resolviendo a fecha de 7 de septiembre a 185.157.160.251.
BleepingComputer informó de que el malware comprueba Linux TracerPid para detectar trazas y sigue instalándose, pero no emite beacon si el rastreo está activo. Esa es una advertencia útil para los defensores: una ejecución silenciosa en un sandbox no demuestra que el binario sea inofensivo.
Si tiene cobertura de SIEM, ahora es cuando demuestra su valor. Correlacione solicitudes web, eventos de correo electrónico de Magento, cambios en cron, creación de procesos, tráfico saliente UDP/123 e inicios de sesión de administradores; una introducción a detección de amenazas en SIEM es pertinente porque revisar un único registro es poco eficaz frente a este tipo de compromiso multietapa.
La rotación de credenciales es más importante que el admin de Magento
Adobe advierte de que la clave de cifrado de Commerce puede proteger tokens de integración, credenciales de pasarelas de pago y tokens de automatización con privilegios. Rotar únicamente la clave de cifrado no invalida las credenciales ya expuestas, por lo que también debe rotarlas en la pasarela de pago o en la fuente de terceros.
Sinceramente, aquí es donde fallan muchas tareas de limpieza. Los equipos cambian las contraseñas de Magento Admin, sienten que han sido productivos y dejan en circulación una clave de API de PSP, un token de ERP, un secreto de integración de envíos o una credencial de automatización que sigue siendo válida.
Regenere los tokens de integración de REST, SOAP y GraphQL. Rote los secretos de cliente OAuth. Cambie todas las contraseñas de Admin, no solo la de la cuenta super-admin más evidente. Después, compruebe si algún usuario de integración tiene más permisos de los necesarios; la verificación de confianza y el principio de privilegio mínimo son útiles aquí porque las integraciones de ecommerce suelen acumular accesos peligrosos a lo largo de los años.
¿Qué pasa con las ramas antiguas? Sansec dice que Adobe no publica ninguna corrección de Magento StyleSmuggler para Magento/Commerce 2.2, 2.3 o 2.4.0 a 2.4.3 porque esas ramas ya no tienen soporte. También afirma que Scandiweb ha hecho backport de correcciones a 41 versiones anteriores, desde 2.2.0 hasta 2.4.3-p3, pero Sansec no había revisado esos parches a fecha de 9 de septiembre de 2026.
Mi opinión: ejecutar una rama de Commerce sin soporte durante un incidente CVSS 10.0 explotado no es un problema de mantenimiento, es una decisión de riesgo empresarial. Un backport puede dar algo de tiempo, según quién lo haya hecho y cómo se haya probado, pero no debería convertirse en el plan a largo plazo.
Qué decir a los clientes, finanzas y la empresa
Los equipos de seguridad suelen querer tener certezas antes de hablar. El ecommerce no siempre le da ese lujo. Si los indicadores sugieren un compromiso, conserve los registros, implique al equipo de respuesta ante incidentes e informe pronto a finanzas y atención al cliente para que sepan qué preguntas sobre pagos, reembolsos y cuentas pueden llegar.
No exagere lo que sabe. Un servidor parcheado significa que el punto de entrada conocido está cerrado; no demuestra que los datos de pedidos, los tokens, las sesiones de administrador o las integraciones de pago no se hayan visto afectados. La formulación prudente es “hemos aplicado el hotfix de Adobe y estamos completando la evaluación del compromiso y la rotación de credenciales”.
Mantén un registro de decisiones fechado. Anota cuándo aplicaste VULN-39341, cuándo comenzó y terminó el modo de mantenimiento, qué claves se rotaron, qué entradas de cron se eliminaron, qué indicadores se comprobaron y quién aprobó volver a activar el checkout. Durante una respuesta caótica a Magento StyleSmuggler, ese registro se convierte en tu memoria.
A los atacantes también les gustan las cadenas de suministro de software y las rutas de actualización, así que, si estás auditando la confianza del despliegue después del incidente, el análisis de cómo el secuestro de BGP puede comprometer las actualizaciones es una lectura complementaria útil. Técnica distinta, misma lección: no des por sentado que la ruta que entrega el código es automáticamente fiable.
Preguntas frecuentes
¿Qué es Magento StyleSmuggler?
Magento StyleSmuggler es el nombre utilizado para CVE-2026-75650, una vulnerabilidad crítica de Adobe Commerce y Magento Open Source divulgada por Adobe el 7 de septiembre de 2026. Permite la ejecución arbitraria de código sin autenticación y está siendo explotada activamente.
¿Adobe tiene un parche para Magento StyleSmuggler?
Sí. Adobe publicó el hotfix VULN-39341 el 7 de septiembre de 2026 y actualizó su guía de la base de conocimiento de Commerce el 9 de septiembre con la asignación de versiones y los pasos de rotación posteriores al parche.
¿Es suficiente desactivar GraphQL para detener el ataque?
No. Antes del hotfix de Adobe, deshabilitar GraphQL se citaba como una contención temporal cuando era operativamente posible. Después de que VULN-39341 estuviera disponible, Adobe y Sansec recomiendan aplicar el hotfix y completar la limpieza en lugar de depender solo del bloqueo.
¿Puedo simplemente restaurar mi tienda Magento desde una copia de seguridad?
No, no de forma segura por sí solo. Sansec advierte que aplicar parches o restaurar no elimina los implantes existentes, la persistencia mediante cron, las credenciales robadas ni las puertas traseras secundarias, por lo que aún necesitas comprobaciones forenses y la rotación de credenciales.
¿Las tiendas Magento 2.2 y 2.3 están cubiertas por la corrección de Adobe?
Sansec afirma que Adobe no publica una solución de StyleSmuggler para Magento/Commerce 2.2, 2.3 o 2.4.0–2.4.3 porque esas ramas ya no tienen soporte. Si utilizas una de ellas, considera la migración o la adaptación retrospectiva revisada de forma independiente como un trabajo urgente de mitigación de riesgos.
ES 
EN 
FR