El zero-day «StyleSmuggler» de Adobe Commerce golpeó tiendas tres días antes del parche

El 4 de septiembre de 2026, a las 22:20 UTC, los atacantes empezaron a golpear tiendas de Magento y Adobe Commerce con un exploit de ejecución remota de código sin autenticación para el que aún no existía parche del fabricante. La vulnerabilidad, registrada como CVE-2026-75650 y bautizada «StyleSmuggler» por la firma neerlandesa de seguridad Sansec, tiene una puntuación CVSS de 10.0, el máximo. Adobe publicó el boletín de emergencia APSB26-146 y el hotfix VULN-39341 el 7 de septiembre, tres días después de la primera intrusión confirmada. Cuando ya existía una solución, los atacantes habían tenido tiempo suficiente para instalar puertas traseras persistentes en las tiendas comprometidas, y el parche no las elimina.

Lectura relacionada: CISA marca PolyShell como explotada mientras la campaña contra Magento alcanza cientos de tiendas · El Patch Tuesday de Microsoft de octubre de 2026 marca un récord con 1.407 correcciones.

Esa brecha es la historia. En una plataforma de comercio electrónico moderna, una vulnerabilidad de ejecución de código sin autenticación es tan grave como puede serlo una vulnerabilidad: la superficie de ataque se reduce a «¿es la tienda accesible desde internet?», y el botín incluye datos de clientes, datos de pago, credenciales de administrador y la capacidad de inyectar skimmers de pago en el proceso de compra. StyleSmuggler resultó no requerir ninguna configuración exótica. Sansec reprodujo la cadena completa en instalaciones limpias de Magento Open Source 2.4.7, 2.4.8 y 2.4.9, y una víctima confirmada ejecutaba 2.4.6-p15 con los parches de julio y agosto aplicados y un informe security:patch-status limpio: prueba de que la comprobación habitual de «¿estamos al día?» no bastaba.

La cadena en dos etapas

StyleSmuggler abusa del sistema de plantillas de Magento de un modo que divide el ataque en una etapa silenciosa y otra que lo desencadena. Primero, un atacante no autenticado envía una petición GraphQL cuya propiedad styles transporta una carga útil de PHP inyectada. La carga no se ejecuta de inmediato; se escribe en disco dentro de un archivo que Magento genera como parte de su funcionamiento normal, como un informe de fallo de pago. Como la carga llega disfrazada de datos de estilo, se cuela por las salvaguardas destinadas a mantener el código ejecutable fuera de las plantillas; de ahí el nombre.

La segunda etapa es la parte ingeniosa. Magento procesa después ese contenido envenenado al construir uno de sus propios correos transaccionales estándar, el «Payment Transaction Failed Reminder». El PHP malicioso se ejecuta en el servidor durante la renderización de la plantilla. Nadie tiene que abrir el correo, y el ataque funciona igualmente si el mensaje nunca se entrega, así que un comerciante que nunca ve un mensaje sospechoso no está a salvo. Sansec señala que una ráfaga inesperada de esos recordatorios de pago fallido sigue mereciendo una investigación, aunque los pagos rechazados normales generan la misma notificación.

La cadena importa porque no depende de un tema mal configurado ni de un administrador descuidado. Sansec informó de que la elección del almacenamiento de sesiones no marca ninguna diferencia y que un operador falló una vez contra una tienda con sesiones respaldadas por Redis y luego lo consiguió ocho segundos después enrutando la carga a través de un archivo subido mediante las opciones personalizadas de Magento. Una tienda estándar en una rama actual estaba dentro del alcance.

Un parche sin número de versión

La remediación de Adobe es inusual, y eso tiene consecuencias para cualquiera que quiera demostrar que está protegido. La empresa no lanzó una nueva versión de Magento o Commerce. En su lugar, el campo de solución de APSB26-146 apunta a la cadena «Hotfix for CVE-2026-75650», entregada como archivo de parche de Composer, VULN-39341-composer-patches.zip, aplicado mediante el proceso de parches de Composer de Adobe. Como señaló la publicación de seguridad Severity Daily, un parche de Composer no mueve la cadena de versión del producto: una tienda que ha aplicado el hotfix y otra que no lo ha hecho informan de la misma versión de Adobe Commerce. Un escáner de vulnerabilidades convencional basado en la coincidencia de versiones no puede distinguirlas. La verificación recomendada por Adobe es un comando de shell en el host (en Cloud, vendor/bin/magento-patches -n status filtrado por 39341), que funciona servidor a servidor pero no escala a una comprobación de cumplimiento de toda la flota.

El rango afectado es amplio. Adobe enumera Adobe Commerce 2.4.4 a 2.4.9, incluidas las versiones de agosto de 2026 y las versiones anteriores de cada rama; Adobe Commerce B2B 1.3.3 a 1.5.3; y Magento Open Source 2.4.6 a 2.4.9. Adobe afirma que el hotfix solo se ha probado contra las versiones de agosto de 2026 de esas ramas y que la compatibilidad con versiones anteriores no está confirmada. Sansec informó por separado de una reproducción en instalaciones limpias de 2.4.7, 2.4.8 y 2.4.9.

Adobe también dejó claro que parchear no es todo el trabajo. Como la vulnerabilidad permite a un atacante ejecutar código como el servidor web, potencialmente queda expuesto todo lo que la tienda podía alcanzar, incluida la clave de cifrado que protege los secretos almacenados. El aviso de la base de conocimiento indica a los comerciantes que roten la clave de cifrado y luego cada credencial que esa clave protegía: contraseñas de administrador, tokens de integración REST, SOAP y GraphQL, secretos de cliente OAuth, credenciales de API de pasarelas de pago, credenciales de bases de datos, claves SSH y de despliegue, y claves de API de extensiones de terceros. Rotar solo la clave, advierte la página, no invalida las credenciales que un atacante ya leyó; hay que rotarlas en el origen, por ejemplo en la pasarela de pago.

Antes de que llegara el hotfix, la mitigación provisional era desactivar GraphQL. Es un compromiso incómodo para las tiendas modernas, impulsadas por API y sin cabecera, que dependen de GraphQL para sus interfaces. No obstante, era la forma más directa de cortar la etapa de inyección mientras no existía una solución.

Una puerta trasera disfrazada de sistema operativo

Lo que convierte a StyleSmuggler en algo más que una historia de parches es lo que dejan atrás los atacantes. El análisis forense de Sansec describe un pequeño programa en Rust que se ejecuta como proceso en segundo plano y se conecta a un servidor de mando y control. Las primeras muestras contactaban con 99.84.67.186; las compilaciones posteriores disfrazan su tráfico como Network Time Protocol, enviando paquetes UDP de 48 bytes al puerto 123 (un puerto y protocolo que la mayoría de los filtros de salida dejan pasar), con solo los primeros cuatro bytes parecidos realmente a NTP. El resto transporta un registro MessagePack con el ID del agente, el nombre de host, el usuario, la versión del sistema operativo, el uso de memoria y disco, el tiempo de actividad, si se ejecuta como root y la versión del implante. Sansec declaró que, con su actualización del 11 de septiembre, el implante resolvía ntp.timesync.to y ntp.timesysnc.net a 185.157.160.251, la dirección que hay que bloquear si no es posible filtrar por nombre.

El implante se oculta a la vista adoptando los nombres de las tareas domésticas habituales de Linux. La primera variante aparecía como [kworker/u:8:0], imitando un hilo trabajador del kernel. Las compilaciones posteriores se renombraron a fc-cache, copiándose a ~/.cache/fontconfig/fc-cache, y luego a chronyd, el nombre real del demonio NTP en la mayoría de las distribuciones. La persistencia proviene de entradas de cron escritas directamente en el spool de cron en lugar de añadirse con crontab -e, de modo que los registros del sistema no contienen ninguna línea REPLACE; las programaciones observadas se ejecutaban cada 30 minutos. Sansec también señaló una variante que puede relanzarse con ID de proceso padre 1 sin ninguna entrada de cron, lo que significa que un crontab vacío no es prueba de un host limpio.

Se observó un segundo operador, no relacionado, en las mismas tiendas víctimas. El 7 de septiembre, Sansec analizó un dropper PHP de 485 bytes que escribe un shell web en la caché de imágenes de producto de Magento bajo pub/media. El shell devuelve un 404 a cualquier petición que carezca del encabezado secreto X-Cache-Token, y cuando el encabezado está presente ejecuta PHP arbitrario desde el parámetro POST task. Sansec recuperó el dropper de un encabezado de petición Store:, todavía con escape JSON del registro en el que Magento lo había anotado, lo que confirma que entró a través de StyleSmuggler. Las dos campañas comparten víctimas pero no herramientas. Las preguntas frecuentes de Tenable sobre la vulnerabilidad informaron de múltiples tiendas víctimas en distintas campañas y de que la firma de respuesta a incidentes Disrex tenía experiencia de primera mano con al menos dos tiendas comprometidas; a 8 de septiembre no había ninguna atribución pública a un grupo de amenazas con nombre.

Parchear cierra el agujero, pero no limpia una tienda que ya fue golpeada. Las tiendas estuvieron siendo explotadas durante tres días antes de que existiera el hotfix.

Por qué este caso golpea más fuerte

Adobe Commerce y Magento gestionan una gran parte de las tiendas en línea del mundo, y muchas de ellas son pequeñas o medianas empresas sin un equipo de seguridad dedicado. Esa combinación amplifica cada propiedad de este incidente. El exploit no necesitaba inicio de sesión, así que la exposición era amplia. La ventana previa al parche se extendió durante un fin de semana en algunas regiones. Y las cargas útiles estaban diseñadas para sobrevivir a la remediación. Un comerciante que parchea el primer día puede seguir alojando a un atacante que llegó el día cero.

También hay una dimensión de cumplimiento normativo. CISA añadió CVE-2026-75650 a su catálogo de vulnerabilidades explotadas conocidas el 8 de septiembre y fijó una fecha límite federal de remediación para el 11 de septiembre, una ventana de tres días mucho más ajustada que las semanas que CISA suele conceder. Esa entrada obliga a las agencias federales a aplicar mitigaciones conforme a las nuevas reglas de parcheo basadas en riesgo y a realizar un triaje forense, el tipo de obligación que se vuelve difícil cuando la remediación es un parche sin número de versión y una lista de comprobación de rotación de credenciales. La conclusión práctica para los operadores del sector privado es la misma: puede que la fecha límite no les obligue, pero la urgencia sí.

El episodio también refuerza un patrón en la seguridad del comercio electrónico. Las capas de plantillas y renderización siguen siendo la vía de entrada, porque se sitúan entre el contenido aportado por el usuario y la ejecución en el servidor, y porque la canalización de correo es fácil de pasar por alto. La recomendación de Sansec de buscar archivos .php recién escritos bajo pub/media es reveladora (ese directorio está destinado a servir imágenes y caché, nunca código), y la monitorización de integridad de archivos está bien preparada para detectar exactamente ese tipo de anomalía.

Qué hay que vigilar

Cuatro cosas determinarán cómo se recuerde este incidente.

Primero, si Adobe convierte el hotfix en una versión numerada. Los parches de Composer son una respuesta de emergencia razonable, pero la ausencia de un número de versión deja ciego a todo inventario de activos y a todo escáner, y hace invisible para las herramientas en las que confían la mayoría de las organizaciones la diferencia entre parcheado y sin parchear.

Segundo, si el implante se convierte en un arma. Cuando Sansec publicó su análisis, no tenía indicios de que la puerta trasera se hubiera usado para algo más que emitir balizas, y el malware no era reconocido por ningún proveedor de seguridad aparte de Sansec. Eso podría cambiar rápidamente.

Tercero, si el shell web del segundo operador es la punta de lanza de una campaña más amplia al estilo Magecart. Un RCE sin autenticación que llega al proceso de pago es un punto de apoyo natural para código de robo de tarjetas, y la ventana entre la primera explotación y la divulgación dio tiempo a los atacantes para posicionarse.

Cuarto, cuántas tiendas fueron realmente comprometidas. Las cifras de víctimas confirmadas siguen siendo pequeñas y anecdóticas. El número real puede aflorar solo cuando los comerciantes realicen evaluaciones de compromiso y encuentren procesos llamados kworker, fc-cache o chronyd que no pertenecen allí. Hasta entonces, la postura honesta para cualquiera que haya operado una tienda Magento expuesta a internet entre el 4 de septiembre y el momento de parchear es asumir el compromiso hasta que se demuestre lo contrario, y rotar las credenciales solo después del parche y de la búsqueda, en ese orden.