# StyleSmuggler: Adobe Commerce tiene un 0-day sin parche y tu tienda puede estar en la fila
**Categoría:** E-Commerce
**Estilo:** crítico
**Fecha:** 2026-09-07
—
El viernes 5 de septiembre, Sansec publicó un aviso que a cualquier responsable de tienda online le debería quitar el sueño: StyleSmuggler, un zero-day en Magento Open Source y Adobe Commerce que permite ejecución remota de código sin autenticación. Los ataques empezaron el 4 de septiembre a las 22:40 UTC. Adobe, tres días después, sigue sin CVE oficial, sin parche y sin workaround publicado. Y la próxima ventana de seguridad programada es el 8 de septiembre, sin garantía de que incluya este fallo.
Si gestionas una tienda en Magento o Adobe Commerce, no te cuento esto como curiosidad técnica. Te lo cuento porque el primer caso confirmado llevaba los parches de julio y agosto de 2026 aplicados, con el security:patch-status limpio. Es decir: habías hecho lo que te dicen que hagas, y aun así estabas expuesto.
Qué hace StyleSmuggler (y por qué el nombre no es casual)
Sansec reprodujo la cadena completa en instalaciones limpias de Magento 2.4.7, 2.4.8 y 2.4.9. Todas vulnerables. El ataque funciona en dos fases que aprovechan el propio motor de plantillas de Magento, no un plugin olvidado ni una contraseña débil.
En la primera fase, el atacante inyecta PHP malicioso en un archivo que Magento escribe durante operaciones normales —informes de fallo de pago, logs del sistema— manipulando propiedades styles dentro de peticiones GraphQL. Esas propiedades pasan filtros que bloquean otros vectores, de ahí el apodo StyleSmuggler: el código entra disfrazado de estilos.
La segunda fase es la que más me preocupa. No hace falta que nadie abra un email ni haga clic en nada. StyleSmuggler provoca que Magento envíe su email estándar de «Payment Transaction Failed Reminder», y el PHP envenenado se ejecuta en el momento en que el sistema renderiza ese mensaje internamente. Sin credenciales. Sin login. Sin interacción humana.
Adobe ausente, merchants solos
Lo que no me cuadra —y lo digo sin rodeos— es el silencio. Según recogen Cybersecurity News y el propio análisis de Sansec, a 6 de septiembre Adobe no había publicado advisory, no había asignado CVE y el último boletín de seguridad de Commerce seguía fechado el 11 de agosto. Mientras tanto, tiendas reales estaban siendo comprometidas.
En mi experiencia, cuando un vendor enterprise tarda más de 48 horas en reconocer un RCE activo en producción, el problema deja de ser solo técnico. Es de confianza. Adobe Commerce cuesta dinero —mucho— y parte de lo que vendes al cliente es que alguien del otro lado vigila esto por ti. StyleSmuggler demuestra que esa promesa tiene agujeros del tamaño de un carrito abandonado.
Y no es que no existan mitigaciones. Sansec recomienda desactivar GraphQL temporalmente en tiendas que no lo necesiten —la mayoría con temas Classic o Hyvä no lo usan—. Disrex ha publicado reglas de nginx/Apache y un parche de emergencia que cierra el sink de include en el escaneo DI, con la advertencia explícita de que no sustituye un fix oficial de Adobe. Son parches de supervivencia, no soluciones.
Headless vs Classic: dos velocidades de pánico
Aquí la cosa se complica. Si tu storefront es headless o PWA, GraphQL no es opcional: es la columna vertebral. Desactivarlo te protege del vector confirmado, pero te apaga la tienda. Es la trampa clásica del comercio moderno: cuanto más desacoplado y «future-proof» te vendieron el stack, más difícil es cortar un servicio sin tumbar el negocio.
Las tiendas Classic tienen una salida más directa. Si no usas GraphQL en producción, bloquearlo ahora mismo es la mitigación con mejor relación esfuerzo/impacto que he visto documentada. Comprueba antes —no asumas—, pero no esperes a que Adobe te mande un email bonito.
Señales de que ya llegaron tarde
Sansec y Disrex han publicado indicadores concretos. Procesos con nombre [kworker/u:8:0] y uso de memoria distinto de cero en contextos donde no deberían aparecer. Entradas de cron sospechosas. PHP inyectado en var/log/system.log o en informes bajo var/report/. Conexiones anómalas a Redis en el puerto 6379.
Si tienes acceso al servidor, revisa esos paths hoy, no el lunes. Y si encuentras un .php donde no toca, asume compromiso completo: rotación de credenciales, revisión de pedidos alterados, aviso a pasarela de pago si procede. Un RCE en el servidor de la tienda no es un «incidente menor».
Lo que esto dice del e-commerce en 2026
StyleSmuggler llega la misma semana en que Shopify presume de vender dentro de ChatGPT y WooCommerce abre APIs para agentes de IA. Todo el sector habla de comercio agéntico y descubrimiento conversacional. Y en el otro lado de la mesa, Adobe Commerce —plataforma que muchas marcas medianas y grandes pagan caro— lleva días con un agujero que permite tomar el servidor entero sin password.
No es una comparación justa en todos los sentidos: Magento y Adobe Commerce son stacks distintos, con modelos de despliegue diferentes. Pero sí es una comparación útil para quien decide dónde poner el dinero del próximo trimestre. La narrativa de «IA en el checkout» pierde mucho brillo cuando la base —el servidor donde vive la tienda— puede caer por un POST anónimo a /graphql.
Tampoco me sirve el argumento de «somos pyme, a nosotros no nos atacan». Sansec detectó la campaña en tiendas sin relación entre sí. Los bots no discriminan por facturación; buscan endpoints expuestos. Y GraphQL en Magento está activo por defecto.
Lo que más me irrita es el calendario. El 8 de septiembre cae el próximo boletín de seguridad de Adobe. ¿Incluirá StyleSmuggler? Nadie lo sabe. Planificar tu respuesta a un RCE activo en función de un calendario editorial de vendor me parece una forma muy bonita de externalizar el riesgo hacia el merchant. Tú sigues vendiendo. Ellos publican cuando toca.
Si dependes de agencia o hosting gestionado, pregunta hoy qué han hecho. No aceptes un «estamos al tanto» genérico. Pide confirmación de si GraphQL sigue abierto, si hay reglas WAF específicas para el vector styles[...], y si han revisado logs desde el 4 de septiembre. Si la respuesta tarda más de un día, ya tienes una señal.
StyleSmuggler no es el primer zero-day en e-commerce y no será el último. Pero sí es un recordatorio incómodo de que parchear a tiempo no basta cuando el fallo aún no tiene parche. En ese escenario, las únicas herramientas reales son visibilidad, mitigación agresiva y la humildad de admitir que tu stack enterprise también sangra.
Si mañana Adobe publicara el fix oficial pero tu agencia te cobrara 800 euros extra por aplicarlo en horas no laborables, ¿lo pagarías sin negociar o revisarías de una vez el SLA de mantenimiento que firmaste hace dos años?