Introducción
Cincuenta minutos. Ese fue el tiempo que tardó un servidor Magento gestionado por una plataforma de desarrollo e-commerce en comprometerse desde que Sansec reportó la primera explotación confirmada de CVE-2026-75650 el 4 de septiembre de 2026 a las 22:20 UTC, según datos publicados por la firma neerlandesa Disrex. No estamos ante una vulnerabilidad teórica con un score inflado: un actor de amenaza ya ejecutó código arbitrario, instaló un backdoor compilado en Rust y dejó una web shell en producción mientras el patch todavía no existía.
Para los equipos de SRE y seguridad que sostienen tiendas Adobe Commerce o Magento Open Source, esto cambia la conversación de «¿cuándo parcheamos?» a «¿ya nos comprometieron y cómo lo detectamos?». El vector no requiere credenciales, no necesita interacción del usuario y se apoya en un flujo legítimo del propio framework: el envío de un email de «Payment Transaction Failed Reminder». Adobe liberó el hotfix VULN-39341 el 8 de septiembre, y CISA incluyó el CVE en su catálogo KEV con deadline de remediación para agencias federales el 11 de septiembre. El margen ya es corto.
Qué ocurrió
Sansec, la firma de seguridad especializada en e-commerce con base en los Países Bajos, identificó explotación in-the-wild de CVE-2026-75650 a partir del 4 de septiembre y la bautizó «StyleSmuggler». El mecanismo abusa del sistema de templates de Magento: un payload de inyección PHP viaja dentro de una solicitud que dispara la generación del email transaccional «Payment Transaction Failed Reminder». El motor de renderizado de plantillas evalúa el código inyectado como si fuera una instrucción legítima del framework, lo que convierte una dependencia de inyección interna (dependency-injection) en una cadena de ejecución remota sin autenticación.
Una vez que el código arbitrario corre en el servidor, los actores ejecutan dos payloads complementarios. Primero, descargan e instalan un backdoor compilado en Rust para Linux que establece una conexión outbound hacia un servidor C2 externo y queda a la escucha de comandos. Segundo, escriben un dropper en PHP que genera una web shell con capacidad de ejecutar código PHP arbitrario, otorgando un canal de acceso persistente y fácil de operar desde un navegador. El uso de Rust para el backdoor principal no es casual: compila a binarios nativos sin dependencias runtime, evade heurísticas de antivirus orientadas a scripts y complica el análisis estático.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El CVSS 10.0 no es decorativo. Significa que no hay mitigación parcial posible sin parche: vector de red, complejidad baja, sin privilegios, sin interacción del usuario y con impacto total en confidencialidad, integridad y disponibilidad. Adobe Commerce y Magento Open Source alimentan más de 250.000 tiendas en línea. Cada instancia expuesta al puerto 443 con la ruta de templates accesible es un objetivo directo.
Para infraestructura cloud, el riesgo se amplifica por tres factores concretos. Primero, el backdoor Rust opera como proceso Linux nativo: no aparece en logs de PHP-FPM ni en WAF rules orientadas a patterns de PHP, lo que lo invisible para monitoreo convencional. Segundo, la web shell PHP puede residir en cualquier directorio con permisos de escritura del usuario www-data o nginx, incluyendo subdirectorios de /pub/media/ que suelen estar fuera del scope de escaneo. Tercero, la conexión C2 del binario Rust puede tunelizarse sobre HTTPS estándar, mezclándose con tráfico legítimo de pasarelas de pago y servicios de terceros.
El caso de los honeypots de Previdian confirma actividad activa: 12 intentos de explotación desde dos direcciones IP (una en China, otra en Rumania) registrados desde el 7 de septiembre de 2026. Que hayan fallado contra honeypots no implica que no hayan tenido éxito contra objetivos reales con configuraciones más laxas.
Detalles técnicos
Versiones afectadas: Adobe Commerce 2.4.7, 2.4.6, 2.4.5, 2.4.4, 2.4.3 y todas sus sub-versiones. Magento Open Source 2.4.7, 2.4.6, 2.4.5, 2.4.4 y 2.4.3. Adobe no especificó versiones anteriores porque el componente de templates involucrado existe desde 2.4.x en adelante.
Componente vulnerable: El engine de procesado de plantillas (Magento\Framework\View\Template) combinado con el flujo de dependency-injection que resuelve la clase del email transaccional. El payload se inyecta como variable de template que el renderizador evalúa como expresión PHP.
Payloads desplegados:
- Backdoor Rust: binario ELF x86_64, conexión outbound a C2, protocolo no revelado (probablemente JSON-over-TCP o HTTP/2), sin strings legibles por strings estándar.
- Web shell PHP: dropper que escribe un archivo .php con funciones eval/system/passthru, accesible vía GET/POST.
Comando de aplicación del parche:
# Descargar el hotfix desde el repositorio oficial de Magento
curl -O https://repo.magento.com/patch/VULN-39341-composer-patches.zip
# Aplicar según tu versión (ejemplo para 2.4.7)
composer require magento/quality-patches:2.4.7-patch-39341
# Rotar claves de criptografía obligatoriamente
bin/magento app:config:import
bin/magento setup:upgrade
bin/magento cache:flush
# Regenerar claves de encryption (CRITICAL)
bin/magento app:config:generate
CISA KEV: CVE-2026-75650 ingresó al Known Exploited Vulnerabilities catalog el 8 de septiembre de 2026. Deadline de remediación para FCEB: 11 de septiembre de 2026.
Adobe simultáneamente parcheó más de 170 vulnerabilidades en su portfolio, incluyendo CVE-2026-82004 (Campaign Classic, CVSS 10.0, command injection) y CVE-2026-48273 / CVE-2026-75746 (ColdFusion, CVSS 9.9 y 9.1). No se reportan exploits in-the-wild para estos últimos.
Qué deberían hacer los administradores y equipos técnicos
1. Aplicar el parche VULN-39341 hoy, no esta semana. Si tu Magento está en una de las versiones listadas, descargá el hotfix desde repo.magento.com/patch/VULN-39341-composer-patches.zip y aplicalo con el flujo de composer require o el script de patching manual. Después, rotá las claves de encryption del env.php (app:config:generate). Sin rotación, un atacante que haya exfiltrado la clave puede descifrar datos de pago y credenciales de API incluso después del parche.
2. Auditar compromisos previos al parche. El binario Rust y la web shell PHP dejan artefactos. Ejecutá:
# Buscar binarios ELF recientes en directorios de escritura
find / -type f -name «*.php» -newer /var/www/magento/pub/index.php -mtime -30
find /tmp /var/tmp /dev/shm -type f -executable -mtime -30
# Revisar procesos Rust/ELF sospechosos con conexión outbound
ss -tnp | grep -v «127.0.0.1» | grep -E «:(443|8080|9001|4444)»
ps aux | grep -v «www-data\|nginx\|mysql\|php-fpm» | grep -E «^\w+\s+\d+»
# Verificar integridad de archivos del core
bin/magento setup:di:info
composer audit
3. Revisar logs de acceso y emails transaccionales. Buscá requests a rutas de templates con payloads PHP ({{, {{php}}, {{var}}) en access logs de nginx/Apache de los últimos 30 días. También revisá colas de emails de «Payment Transaction Failed Reminder» con metadatos anómalos en los headers.
4. Hardening inmediato mientras aplicás el parche. Si no podés parchar en las próximas 4 horas, restringí el acceso a la ruta de templates a IPs internas y bloqueá el endpoint de generación de emails transaccionales en el WAF. Desactivá allow_url_include y enable_dl en php.ini. Verificá que el usuario de PHP-FPM no tenga permisos de escritura sobre /pub/media/ más allá de subidas legítimas.
5. Actualizar dependencias Rust/Go en tu toolchain interna. Si usás herramientas de infraestructura compiladas en Rust o Go, verificá que no compartan librerías de red o cripto con el binario del backdoor. Red Hat y el ecosistema Go publican advisories de dependencias con frecuencia; sus blogs son referencia para CVEs de tooling.
Conclusión
StyleSmuggler demuestra que la superficie de ataque de un framework e-commerce no se limita a sus endpoints REST o GraphQL: el propio motor de renderizado de templates se convirtió en un vector de RCE con CVSS 10.0. El uso de Rust para el backdoor principal marca una tendencia que los equipos de detección tienen que anticipar: binarios nativos, sin strings, sin dependencias interpretables, que no dejan rastro en los logs de PHP.
La ventana entre la primera explotación (4 de septiembre) y la publicación del parche (8 de septiembre) fue de cuatro días. En esos cuatro días, servidores comprometieron en menos de una hora. Si tu Magento está expuesto, la pregunta no es si parchar, es cuánto tiempo vas a seguir expuesto. Aplicá VULN-39341, rotá claves, auditar y documentá. Después, revisá por qué tu pipeline de patching de terceros no detectó la exposición antes del exploit.
Fuentes
- https://thehackernews.com/2026/09/adobe-patches-magento-zero-day.html
- https://www.redhat.com/en/blog
- https://go.dev/blog/