Adobe publicó el 7 de septiembre a las 20:20 UTC un parche de emergencia para CVE-2026-75650, un fallo de puntaje 10,0 en Magento Open Source y Adobe Commerce que permite a un atacante sin autenticarse ejecutar código en el servidor de la tienda. En su aviso lo dice sin rodeos:

Adobe tiene conocimiento de que CVE-2026-75650 ha sido explotado en la vida real contra comercios de Adobe Commerce.

La empresa neerlandesa Sansec, que investiga seguridad de comercio electrónico, detectó la primera explotación confirmada el 4 de septiembre a las 22:20 UTC y publicó un aviso temprano al día siguiente, con el fallo todavía sin parche. Le puso nombre: StyleSmuggler.

Entre esas dos fechas hubo casi tres días con tiendas comprometiéndose y sin corrección disponible. Por eso la parte más importante de esta nota no es el parche: es cómo comprobar si tu tienda ya está adentro de esa lista.

Qué versiones de Magento y Adobe Commerce están afectadas

Del aviso de Adobe, APSB26-146:

ProductoVersiones afectadas
Adobe Commerce2.4.4 hasta 2.4.9 (2026-aug y anteriores)
Magento Open Source2.4.4 hasta 2.4.9 (2026-aug y anteriores)
Adobe Commerce B2B1.3.3 hasta 1.5.3 (2026-aug y anteriores)

Corrige el parche VULN-39341, que Adobe distribuye como VULN-39341-composer-patches.zip y que aplica a todas las versiones de la lista. Sansec confirmó la explotación sobre instalaciones limpias de 2.4.7, 2.4.8 y 2.4.9, o sea que estar en la versión más nueva no protegía.

Prácticamente toda la línea 2.4 en uso está alcanzada. Si tenés una tienda Magento andando, asumí que te toca hasta comprobar lo contrario.

Cómo funciona StyleSmuggler, sin entrar en el exploit

Sansec describe un ataque de dos etapas. Primero el atacante inyecta código PHP, por ejemplo haciendo que se genere un reporte de falla. Después consigue que Magento ejecute ese código a través del correo de "pago fallido" que la tienda manda sola. El truco para pasar los controles existentes está en las propiedades styles del sistema de plantillas, y de ahí el nombre.

Lo interesante para el que se defiende es la forma: el disparador es una función legítima y automática de la tienda. Nadie tiene que hacer clic en nada. El correo de recordatorio de pago fallido se genera solo, y esa generación es la que ejecuta lo que el atacante dejó sembrado.

Dos etapas, y la segunda la dispara la propia tienda 1. Siembra un atacante sin autenticar deja código PHP guardado 2. Ejecuta la tienda al generar el correo automático de pago fallido Nadie hace clic en nada: el disparador es una función normal del sistema

Es la misma familia de problema que vimos con el formulario de Elementor Pro que dejaba subir un PHP: una función pensada para el negocio termina siendo el camino de ejecución.

Por qué el parche de Magento no echa al que ya entró

Acá está lo que más se va a saltear, y es la instrucción del propio fabricante. El aviso de Adobe no dice "actualizá": dice "apliquen el parche VULN-39341 (según su versión) y roten sus claves de cifrado", y detalla un procedimiento de catorce pasos que incluye deshabilitar el cron, rotar credenciales de las pasarelas de pago, regenerar los tokens de integración y vaciar la caché antes de volver a operar.

La razón es simple y desagradable: el atacante que entró antes del parche tuvo acceso al servidor de la tienda, y ahí viven las claves de cifrado de Magento y, con ellas, las credenciales de las pasarelas de pago y los tokens de las integraciones. Parchear cierra la puerta. No cambia las llaves que ya se copiaron.

Lo que hace el parche y lo que no El parche VULN-39341 cierra la entrada Ningún atacante nuevo puede usar esta vía Es el paso 1 de 14 que exige Adobe, no el único Lo que el parche no deshace Claves de cifrado, credenciales de pasarelas y tokens ya copiados Y cualquier backdoor que haya quedado instalado en el servidor Una tienda parcheada y sin rotar claves sigue siendo una tienda abierta

¿Cómo sé si mi tienda Magento ya está comprometida?

Sansec publicó indicadores concretos, y esta es la parte accionable hoy.

Procesos disfrazados. Los atacantes despliegan un backdoor escrito en Rust que se hace pasar por servicios legítimos del sistema, con nombres como [kworker/u:8:0], fc-cache o chronyd. En el servidor:

ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'
crontab -l | grep -i gvfsd

Archivos PHP donde no debería haberlos. Un segundo grupo de atacantes deja shells web en la carpeta de caché de imágenes de productos, con rutas del tipo pub/media/catalog/product/cache/ss_<10 caracteres hex>/sync_<10 hex>.php. En la raíz de la tienda:

find pub/media -name '*.php'

Esa carpeta guarda imágenes. Cualquier archivo PHP ahí adentro es sospechoso por definición, haya o no relación con este ataque.

Conexiones salientes. Sansec señala un servidor de mando y control en 99.84.67.186. Buscalo en los registros del firewall y del servidor.

Que los comandos no devuelvan nada no cierra el caso —el nombre del proceso y la ruta del archivo pueden cambiar entre campañas— pero que devuelvan algo lo abre de inmediato.

¿A quién afecta CVE-2026-75650?

  • A cualquier tienda con Magento Open Source o Adobe Commerce en la línea 2.4, entre 2.4.4 y 2.4.9.
  • También a Adobe Commerce B2B entre 1.3.3 y 1.5.3.
  • Da igual el tamaño: el ataque es automático y barre internet buscando tiendas, no elige clientes grandes. Es el mismo barrido indiscriminado que dejó seis fallas de Citrix NetScaler explotándose en agosto.

¿Quién puede ignorar el aviso de Magento?

  • Quien no usa Magento ni Adobe Commerce. No aplica a WooCommerce, Shopify, Tiendanube, PrestaShop ni a ninguna otra plataforma.
  • Quien ya aplicó VULN-39341 y completó la rotación de claves. Aplicar solo el parche no alcanza.
  • Quien está en Adobe Commerce como servicio administrado y ya recibió confirmación de su proveedor de que aplicó el parche. Conviene pedir esa confirmación por escrito, no suponerla.

Qué hacer con la tienda Magento hoy, en orden

  1. Aplicá VULN-39341. Adobe lo clasificó como prioridad 1, la más alta que usa.
  2. Corré los tres comandos de detección antes de dar por cerrado el tema. Si aparece algo, esto pasa de ser una actualización a ser un incidente, y el orden de trabajo cambia.
  3. Seguí el procedimiento de catorce pasos de Adobe, no solo el parche: deshabilitar el cron, rotar claves de cifrado, rotar credenciales de las pasarelas de pago, regenerar tokens de integración, vaciar caché y recién ahí volver a operar.
  4. Avisale a tu proveedor de hosting. Si la tienda está en un hosting administrado, pueden tener registros del servidor que vos no ves y ayudarte a confirmar si hubo ejecución.
  5. Revisá los pedidos y los datos de pago de los últimos días. Una tienda comprometida es, ante todo, un problema de datos de clientes, y eso activa obligaciones de notificación que conviene tener claras antes y no durante — están en lo que exigen las aseguradoras.

Si nunca definiste quién es responsable de actualizar la tienda —vos, la agencia o el hosting—, ese es el problema de fondo, y está tratado en qué cubre el hosting y qué no en la seguridad de tu sitio.

Preguntas frecuentes sobre CVE-2026-75650 en Magento

Ya actualicé, ¿estoy seguro?

Solo si además rotaste las claves de cifrado y las credenciales. Adobe lo exige explícitamente en el mismo aviso. Si la tienda fue comprometida antes del parche, el atacante pudo llevarse esos secretos y siguen sirviéndole después de actualizar.

Mi tienda es chica, ¿por qué la atacarían?

Porque nadie la eligió. La explotación de este tipo de fallas es automática: se barre internet buscando instalaciones vulnerables y se ataca todo lo que responde. El tamaño del negocio no entra en la ecuación.

Uso WooCommerce sobre WordPress, ¿me afecta?

No. Es una falla del código de Magento y Adobe Commerce. WooCommerce, Shopify, PrestaShop y Tiendanube usan bases de código distintas.

¿Cómo puede ejecutarse código sin que nadie haga clic?

Porque la segunda etapa la dispara la propia tienda al generar el correo automático de aviso de pago fallido. El atacante deja el código guardado y espera a que una función normal del sistema lo procese.

Los indicadores los publicó Sansec, que vende productos de seguridad. ¿Son confiables?

Los comandos de detección son genéricos y no dependen de comprar nada: miran procesos, tareas programadas y archivos PHP fuera de lugar. Sansec efectivamente vende herramientas de escaneo y bloqueo, y las recomienda en su propio aviso; corresponde saberlo al leer esa parte. Los datos técnicos coinciden con el aviso de Adobe, que es independiente.


Fuentes primarias. Investigación de Sansec sobre StyleSmuggler, publicada el 5 de septiembre de 2026 y actualizada el 7 · Aviso APSB26-146 de Adobe, del 7 de septiembre de 2026.

Consultadas el 8 de septiembre de 2026. Para el vocabulario, el glosario; para el orden general de prioridades, la guía de ciberseguridad para PyMEs de LATAM. El patrón de parchear sin revisar si ya hubo acceso apareció también en la central Switchvox explotada la semana pasada.