¿Qué es Style Smuggler (CVE-2026-75650)?

Resumen

• Sansec descubrió la vulnerabilidad en Adobe Commerce & Magento y detectó que ya se explotaba antes de que se liberaran los parches, desde el 4 de septiembre de 2026

• Adobe publicó APSB26-146 el 7 de septiembre de 2026 para abordar partes de la cadena de vulnerabilidades

• Fastly liberó un parche virtual para CVE-2026-75650 que los clientes pueden habilitar para bloquear las solicitudes dirigidas a la vulnerabilidad

Análisis de la vulnerabilidad

CVE-2026-75650 es una vulnerabilidad de inyección de plantillas del lado del servidor (SSTI) que no requiere autenticación y permite directamente la ejecución remota de código (RCE). Explotar la vulnerabilidad ocurre en tres etapas a lo largo de cuatro solicitudes: 

1. Inyección de código PHP en los log 

2. Configuración del carrito e inserción de la carga útil de SSTI en los datos de dirección del carrito 

3. Ejecución de la SSTI y ejecución remota de código mediante un correo electrónico de pago fallido

Etapa 1: inserción de código PHP en los log

La primera etapa consiste en introducir código PHP sin sanear en el disco del sistema objetivo. Reprodujimos un método en nuestros laboratorios, y se ha observado al menos otro método confirmado en ataques reales. Es importante señalar que probablemente existen muchas otras formas de completar esta etapa. La variante que reprodujimos localmente registra en un log un mensaje de error sin escapar procedente de un código de tienda no válido, lo que conserva el código PHP malicioso incluido en la solicitud. Una solicitud se vería más o menos así:

POST /graphql HTTP/1.1
Host: {{Hostname}}
Content-Type: application/json
Store: <?=eval(base64_decode('{{payload_b64}}'));?>

{"query":"{ storeConfig { store_code } }"}

El encabezado Store es donde se inserta la carga útil y, en ataques reales, probablemente incluirá contenido codificado para evadir la detección. Cuando Magento registra este error en el log, <?= se registra sin escapar, lo cual será importante al llegar a la etapa 3. El código PHP concreto variará durante la explotación.

Etapa 2: inserción de una carga útil de SSTI en los datos de dirección

La segunda solicitud configura un carrito de invitado, y la tercera solicitud contiene la carga útil de SSTI en la dirección del carrito. La segunda solicitud no tiene nada de particular, así que se omite por brevedad.

Para entender la carga útil de SSTI, es necesario conocer algunas partes del motor de plantillas de Magento. El motor de plantillas de Magento sustituye variables mediante “directivas” (p. ej., var, block), que se identifican mediante distintas expresiones regulares para cada directiva. Un “filtro” se encarga de procesar las directivas y lo hace en dos pasadas. En la primera pasada, el filtro resuelve las directivas que puede y, en la segunda, procesa las directivas “diferidas” que un filtro anidado ha firmado. Cuando se procesa una directiva, esta tiene un filtro principal y su resultado es idéntico a la propia directiva, se “firma” (es decir, *Sig*{{directive}}*Sig*) para que el filtro principal la resuelva. 

Aquí es donde empiezan los problemas. Cuando se firma una directiva, se usa str_replace en la salida para sustituir la directiva original por la firmada. Sin embargo, la salida incluye todas las directivas procesadas anteriormente, no solo la actual. Así que veamos en detalle cómo Style Smuggler utiliza estas directivas.

Style Smuggler utiliza una plantilla de correo electrónico de pago fallido que parsea los campos de dirección con un filtro anidado. El filtro que procesa la dirección no puede procesar directivas block. Por eso, enviamos lo siguiente en los campos de dirección de la tercera solicitud:

street: {{if postcode}}{{var postcode}}{{/if}}{{/var}}{{if postcode}}{{var postcode}}{{/if}}{{if city}}{{block class=Magento\\Email\\Block\\Adminhtml\\Template\\Preview}}{{/if}}

postcode: {{var postcode}}

Cuando el filtro de direcciones procesa el código postal, este coincide con el contenido original de la directiva y se firma. Sin embargo, como str_replace se aplica a toda la salida, las firmas también se colocan donde insertamos {{var postcode}} en la parte de la dirección correspondiente a la calle. Debido a cierta confusión en la expresión regular que identifica las directivas, la dirección final “procesada” se pasa al filtro de correo electrónico con {{var postcode}}{{var postcode}}Sig{{blockclass=Magento\\Email\\Block\\Adminhtml\\Template\\Preview}}Sig<br /> Entonces, el filtro de correo electrónico resuelve la directiva de bloque firmada que introdujimos en la parte de la dirección correspondiente a la calle. Antes del parche de Adobe, las directivas de bloque creaban una instancia de la clase proporcionada, fuera o no una clase “Block”. Por tanto, ahora podemos crear objetos arbitrarios.

Etapa 3: conversión de SSTI en RCE

En este punto tenemos 1) código PHP en un archivo de log y 2) una SSTI capaz de crear instancias de clases arbitrarias. Para conectar ambas cosas, necesitamos crear una instancia de una clase que pueda ejecutar el código que introdujimos en el archivo de log en la etapa 1. Aquí es donde cobra importancia Magento\Email\Block\Adminhtml\Template\Preview, que insertamos previamente. Es una clase que puede renderizar plantillas a partir de los parámetros de consulta “text”, “styles” y “type”. Así que enviaremos una solicitud con los siguientes parámetros de consulta (codificados para URL):

text: {{block class=Magento\Backend\Block\Widget\Grid\ColumnSet rowUrl=$this.template_styles cache_key=y}}

styles (con formato de parámetro de consulta codificado en JSON):

 {
    "first": "../var/log/system.log",
    "generatorClass": "Aws\\S3\\S3Client",
    "region": "us-east-1",
    "version": "latest",
    "s3_us_east_1_regional_endpoint": "regional",
    "with_resolved": [
      {
        "instance": "Magento\\Setup\\Module\\Di\\Code\\Scanner\\ArrayScanner"
      },
      "collectEntities"
    ],
    "path": "dummy"
  }

type: 2

En esta solicitud, también usamos simultáneamente la mutación graphql handlePayflowProResponse para iniciar el procesamiento de la plantilla de pago fallido. Esto desencadena la siguiente secuencia de eventos:

1. El bloque “Preview” que insertamos previamente se procesa durante el procesamiento de la plantilla de correo electrónico, lo que hace que se cree nuestro otro bloque con carga útil, “ColumnSet”, a partir del parámetro de consulta “text”.

2. ColumnSet recibe el arreglo “styles” como argumento y llama a “UrlGeneratorFactory” con “Aws\S3\S3Client” como la clase de generador que proporcionamos.

3. Durante la construcción de S3Client, se crea una instancia de “Magento\Setup\Module\Di\Code\Scanner\ArrayScanner”, que proporcionamos, y se llama al método “collectEntities”

4. collectEntities llama a “include” sobre el valor “first” que proporcionamos dentro del arreglo styles, que corresponde al archivo de log que contaminamos. 

5. El código que colocamos en el archivo de log se ejecuta durante la inclusión (debido a que <?= no está escapado) y ahora tenemos RCE. 

De ahí viene el nombre “Style Smuggler”. Utiliza el parámetro “styles” que usa la clase Preview para introducir la información adicional sobre el gadget necesaria para ejecutar código. También es importante señalar que podrían existir otros gadgets utilizables en el código base de Magento y que hemos identificado al menos una variante que usa una carga útil distinta del bloque “Preview”.

Plantilla de Nuclei

Para ayudar a la comunidad a detectar instancias vulnerables a Style Smuggler, enviamos una plantilla de Nuclei para CVE-2026-75650 al repositorio oficial nuclei-templates. Aunque desarrollamos la plantilla, esperamos para enviarla hasta que Graycore hiciera una publicación de un análisis de la vulnerabilidad y Sansec lo reconociera, para evitar divulgar información que hasta entonces no se había hecho pública. Probamos la plantilla localmente con Magento v2.4.9 y v2.4.7-p2 para asegurarnos de que funcionara correctamente en varias versiones.

Parche virtual para CVE-2026-75650

Fastly ha liberado un parche virtual para CVE-2026-75650 que cubre cada etapa de explotar de Style Smuggler. Esto proporciona defensa en profundidad frente a variantes en una parte de la cadena y da tiempo a los operadores para aplicar parches a sus sistemas. Este parche virtual evita los falsos positivos durante las operaciones normales, incluidas las actualizaciones de plantillas de administración, y no está relacionado con los falsos positivos descritos en otros artículos.