Adobe publicó el 7 de septiembre de 2026, a las 20:20 UTC, el boletín APSB26-146 con prioridad 1 —la más alta de su escala— para corregir CVE-2026-75650 en Adobe Commerce y Magento Open Source. La vulnerabilidad tiene puntaje CVSS 10.0 y permite ejecución remota de código sin autenticación previa. No es una hipótesis de laboratorio: la firma de seguridad Sansec, que la bautizó StyleSmuggler, documentó explotación activa como día cero desde el 4 de septiembre, tres días antes de que existiera parche.
Cómo funciona el ataque
La falla abusa del sistema de plantillas de Magento mediante inyección de código PHP en el flujo que genera el correo de recordatorio de transacción de pago fallida. Ese correo, pensado para recuperar carritos con pagos rechazados, termina siendo el vehículo que dispara la ejecución de código en el servidor.
Están afectadas todas las versiones desde la 2.4.4 hasta la 2.4.9 inclusive. Los atacantes observados no se quedan en la prueba de concepto: despliegan una puerta trasera para Linux escrita en Rust que se conecta a un servidor externo y queda esperando instrucciones, además de un web shell en PHP. Es decir, buscan persistencia, no una defacement rápida.
La instrucción que casi nadie ejecuta completa
Adobe no se limitó a pedir que se aplique el parche. Recomienda además rotar la llave de cifrado de la instalación y todas las credenciales que esa llave protegía. La lista es larga y ahí está el trabajo real:
- Contraseñas de administrador.
- Tokens de integración REST, SOAP y GraphQL.
- Secretos de cliente OAuth.
- Credenciales de API de las pasarelas de pago.
- Credenciales de base de datos.
- Llaves SSH y de despliegue.
- Llaves de API de extensiones de terceros.
La razón es simple y desagradable: si el atacante ejecutó código en el servidor antes del parche, tuvo acceso a la llave y, por lo tanto, a todo lo que esa llave descifra. Parchear cierra la puerta, pero no revoca lo que ya salió por ella. Una tienda que aplique el parche y no rote credenciales puede seguir comprometida con acceso legítimo durante meses, sin que ningún escáner de vulnerabilidades levante una alarma.
El problema de fondo: nadie tiene el inventario
Aquí es donde la mayoría de las organizaciones se traba. Rotar la llave de cifrado exige saber qué integraciones dependen de ella, quién es dueño de cada token, qué sistema se rompe si un secreto cambia, y en qué orden hay que hacerlo para no dejar la tienda fuera de línea. Ese inventario rara vez existe, y cuando existe suele estar desactualizado o repartido entre el proveedor que hizo la implementación original, el que la mantiene hoy y un archivo que nadie abre desde hace dos años.
El resultado previsible es que muchas tiendas van a aplicar el parche, marcar el ticket como resuelto y detenerse justo antes de la parte que importa. La ventana de exposición no la define la fecha del parche, sino la fecha de la última rotación de credenciales.
Qué hacer esta semana
Si opera Adobe Commerce o Magento entre 2.4.4 y 2.4.9: aplique el parche de inmediato, y asuma compromiso si la instancia estuvo expuesta a internet entre el 4 y el 7 de septiembre. Revise procesos inusuales, tareas programadas nuevas, archivos PHP modificados fuera de la ruta de despliegue y conexiones salientes hacia destinos desconocidos. Después, ejecute la rotación completa.
Este incidente ilustra algo que va más allá del comercio electrónico: la seguridad de una plataforma empresarial no depende solo de su código, sino de la trazabilidad de sus integraciones. En TEKFENIX construimos software empresarial a medida partiendo de esa premisa —cada integración documentada, cada credencial con dueño identificable y rotación prevista desde el diseño— y esa misma lógica de evidencia y trazabilidad es la que sostiene CumplimientoControl. Un incidente se responde con el inventario que ya se tenía, no con el que se improvisa a las once de la noche.