Un zero-day sin parche en Adobe Commerce y Magento deja 160,000 tiendas expuestas

La falla StyleSmuggler permite ejecución remota de código en todas las versiones de Magento y Adobe Commerce, incluidas instalaciones con parches al día. El primer ataque se detectó el 4 de septiembre.

Una vulnerabilidad de día cero bautizada StyleSmuggler se explota activamente contra tiendas construidas sobre Magento y Adobe Commerce. El alcance potencial supera los 160,000 sitios, entre ellos unos 14,000 del millón de dominios más visitados del mundo.

Cómo funciona el ataque

El atacante abusa del sistema de plantillas de Magento mediante inyección de código PHP. Con eso genera un correo falso de «pago fallido» cuya construcción dispara la ejecución del código inyectado en el servidor.

La carga final es un backdoor escrito en Rust que se disfraza de procesos legítimos del sistema, con nombres como kworker/u:8:0 o fc-cache. Mantiene persistencia a través de tareas cron que se repiten cada 30 minutos, determina la dirección IP del servidor comprometido y detecta si alguien está trazando su actividad antes de comunicarse con su infraestructura remota para recibir comandos.

El detalle que cambia el cálculo de riesgo

La firma de seguridad Sansec documentó el primer ataque el 4 de septiembre contra un objetivo que corría las actualizaciones de seguridad más recientes. Estar al día con los parches no ofreció protección, porque la falla seguía sin corrección disponible.

El soporte empresarial de Adobe confirmó que trabaja en una solución sin comprometer fecha de liberación. Su ventana de seguridad programada correspondía al 8 de septiembre. Mientras tanto, Sansec recomienda deshabilitar GraphQL como contención provisional.

Qué significa para el comercio electrónico regional

Magento sostiene una porción relevante del comercio electrónico de gama media y alta en América Latina, incluida República Dominicana, donde varias tiendas de retail y distribución operan sobre esa base. El perfil del ataque apunta directo al eslabón más sensible: el checkout y los datos de pago.

La postura defensiva razonable parte de asumir compromiso hasta probar lo contrario. Eso implica revisar tareas cron no reconocidas, buscar procesos con los nombres señalados, auditar los registros del servidor de correo en busca de plantillas de «pago fallido» generadas fuera del flujo normal, y aislar GraphQL del acceso público mientras llega el parche.

El caso también expone una asimetría conocida: el operador de la tienda depende del calendario de un proveedor para cerrar una puerta que ya está abierta. Los contratos de mantenimiento que no contemplan ventanas de emergencia dejan al comerciante esperando.

Fuentes