Vulnerabilidad sin parche explotada activamente
Una vulnerabilidad sin parche en Magento Open Source y Adobe Commerce está siendo explotada activamente por atacantes para ejecutar código arbitrario en los servidores de tiendas en línea, sin necesidad de credenciales de acceso. La empresa de seguridad neerlandesa Sansec, que descubrió la falla y la denominó StyleSmuggler, informó que los ataques comenzaron el 4 de septiembre. Según la compañía, las tiendas están siendo comprometidas en este momento, por lo que decidieron publicar la alerta de manera temprana. Hasta el 6 de septiembre, Adobe no había publicado ningún aviso oficial, identificador CVE, parche o medida de mitigación. Su índice de boletines de seguridad de Adobe Commerce no muestra ninguna actualización después del 11 de agosto. Sansec ha confirmado que todas las versiones actuales están afectadas, incluidas la 2.4.9, y ha reproducido la cadena completa de explotación sin autenticación en instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9.
Naturaleza de los ataques
Un ataque exitoso permite al atacante ejecutar código en el servidor de la tienda e instalar una puerta trasera persistente. El primer afectado conocía ejecutaba Magento 2.4.6-p15 con las actualizaciones de seguridad de julio y agosto de 2026 de Adobe. Disrex Group, una empresa de desarrollo y hosting de Magento que respondió a dos incidentes, publicó hallazgos independientes que confirman la explotación en curso.
Indicadores de compromiso
Sansec describe el malware como un proceso en segundo plano disfrazado con el nombre [kworker/u:8:0], que corresponde a un hilo del kernel de Linux. El binario se instala en ~/.local/share/.gvfsd/gvfsd-user bajo el directorio del usuario del sitio, y una entrada cron lo reinicia cada cinco minutos. Disrex identificó el binario como un programa en Rust, estáticamente enlazado y de aproximadamente 1.9 MB, compilado para x86-64 y arm64. La entrada cron se escribe directamente en el archivo de spool, evitando que aparezca en el registro del sistema. En una de las tiendas comprometidas, el implante no realizaba conexiones salientes, sino que mantenía 28 conexiones con la instancia de Redis local para leer el almacenamiento de sesiones. Disrex documentó tres hashes SHA-256 diferentes del malware: uno de la muestra de Sansec (e315…), uno en disco en las tiendas afectadas (8334…) y otro en memoria en una de ellas (251b…). Además, se ha observado tráfico hacia el dominio de descarga 247.cdnflare[.]xyz y hacia direcciones IP de comando y control.
Mitigaciones y recomendaciones
Dado que Adobe aún no ha publicado un parche, Sansec recomienda deshabilitar GraphQL temporalmente. Sin embargo, Disrex señala que las tiendas headless y las aplicaciones web progresivas requieren GraphQL, por lo que esta medida no es universal. Se han publicado mitigaciones no oficiales por parte de Disrex, ProxiBlue y Graycore, así como configuraciones de servidor que pueden bloquear parte de los ataques.
Eso es hardening, no un fix – Graycore, en su módulo de mitigación, advirtiendo que otras vías de explotación pueden permanecer abiertas.
Proceso de infección y limpieza
La cadena de explotación consta de dos etapas: primero, se inyecta código PHP en un archivo que Magento escribe, como un informe de error; luego, se fuerza a Magento a ejecutar ese archivo mediante el correo de 'Recordatorio de transacción fallida' (Payment Transaction Failed Reminder). El código se ejecuta al renderizar el mensaje, sin necesidad de interacción del usuario. Sansec no ha publicado la cadena completa, pero los indicadores de compromiso incluyen procesos con nombres de kernel ejecutados por usuarios no root y archivos en directorios como /tmp o ~/.local/share. Para una tienda ya infectada, se recomienda preservar la evidencia primero, eliminar la entrada cron antes de matar el proceso (ya que el proceso la restaura), no reiniciar el servidor (el binario puede perderse) y no ejecutar composer install para limpiar, pues sobrescribiría las marcas de tiempo. Luego, se deben rotar todas las credenciales, incluyendo las claves de pago y la crypt/key en app/etc/env.php.
Respuesta de los proveedores de hosting
Los proveedores de hosting Nexcess y Liquid Web han publicado avisos indicando que están revisando sus entornos y tomando medidas preventivas. Sin embargo, ninguna de las partes ha revelado la identidad de los atacantes ni ha confirmado un número total de tiendas comprometidas. The Hacker News ha contactado a Adobe, Sansec, Disrex Group y Graycore para obtener comentarios, y actualizará la noticia en caso de recibir respuesta.
Deja una respuesta