Che cos’è Style Smuggler (CVE-2026-75650)?

Panoramica

• Sansec ha scoperto la vulnerabilità in Adobe Commerce & Magento e ha rilevato che veniva sfruttata prima del rilascio delle patch, già il 4 settembre 2026

• Adobe ha pubblicato APSB26-146 il 7 settembre 2026 per correggere alcune parti della catena di vulnerabilità

• Fastly ha rilasciato una patch virtuale per CVE-2026-75650 che i clienti possono abilitare per bloccare le richieste che prendono di mira la vulnerabilità

Analisi della vulnerabilità

CVE-2026-75650 è una vulnerabilità di Server-Side Template Injection (SSTI) che non richiede autenticazione e consente direttamente l’esecuzione di codice da remoto (RCE). L’exploit della vulnerabilità si articola in tre fasi distribuite su quattro richieste: 

1. Inserimento di codice PHP dannoso nei log 

2. Configurazione del carrello e inserimento del payload SSTI nei dettagli dell’indirizzo del carrello 

3. Sfruttamento della SSTI e conseguente RCE tramite un’email relativa a un pagamento non riuscito

Fase 1: inserimento di codice PHP nei log

La prima fase consiste nel salvare codice PHP non sottoposto a sanitizzazione sul disco del sistema bersaglio. Abbiamo riprodotto un metodo nei nostri laboratori, mentre almeno un altro metodo confermato è stato osservato in attacchi reali. È importante notare che probabilmente esistono molti altri modi per completare questa fase. La variante che abbiamo riprodotto localmente registra nei log un messaggio di errore senza escape, generato da un codice del negozio non valido, conservando il codice PHP dannoso incorporato nella richiesta. Una richiesta potrebbe presentarsi così:

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

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

Il payload viene inserito nell’intestazione Store e, negli attacchi reali, conterrà probabilmente contenuti codificati per eludere i controlli. Quando Magento registra questo errore nei log, <?= viene registrato senza escape, un dettaglio importante per la fase 3. Il codice PHP effettivo varia durante lo sfruttamento della vulnerabilità.

Fase 2: inserimento di un payload SSTI nei dettagli dell’indirizzo

La seconda richiesta configura un carrello per un utente non registrato, mentre la terza richiesta contiene il payload SSTI nell’indirizzo associato al carrello. La seconda richiesta non presenta elementi interessanti, quindi viene omessa per brevità.

Per comprendere il payload SSTI, occorre conoscere alcune parti del motore dei template di Magento. Il motore dei template di Magento sostituisce le variabili usando «direttive» (ad esempio, var e block), identificate tramite espressioni regolari diverse per ciascuna direttiva. Un «filtro» è responsabile dell’elaborazione delle direttive, che avviene in due passaggi. Nel primo passaggio, il filtro risolve tutte le direttive che può; nel secondo, elabora le direttive «differite» firmate da un filtro annidato. Quando una direttiva viene elaborata, ha un filtro padre e il suo output coincide con la direttiva stessa, viene «firmata» (ovvero *Sig*{{directive}}*Sig*) affinché il filtro padre possa risolverla. 

È qui che iniziano i problemi. Quando una direttiva viene firmata, si usa str_replace sull’ output per sostituire la direttiva originale con quella firmata. Tuttavia, l’output include tutte le direttive elaborate in precedenza, non solo quella corrente. Vediamo quindi come Style Smuggler sfrutta queste direttive.

Style Smuggler sfrutta un modello di email relativo a un pagamento non riuscito che analizza i campi dell’indirizzo con un filtro annidato. Il filtro che elabora l’indirizzo non può elaborare le direttive block. Nei campi dell’indirizzo della terza richiesta inviamo quindi quanto segue:

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}}

Quando il filtro degli indirizzi elabora il codice postale, questo corrisponde al contenuto della direttiva originale e viene firmato. Tuttavia, poiché str_replace viene applicato all’intero output, le firme vengono inserite anche nel punto in cui abbiamo aggiunto {{var postcode}} nella parte dell’indirizzo relativa alla via. A causa di un’ambiguità nell’espressione regolare che identifica le direttive, l’indirizzo «elaborato» finale viene passato al filtro delle email e contiene {{var postcode}}{{var postcode}}Sig{{blockclass=Magento\\Email\\Block\\Adminhtml\\Template\\Preview}}Sig<br /> Il filtro delle email risolve quindi la direttiva block firmata che abbiamo introdotto nella parte dell’indirizzo relativa alla via. Prima della patch di Adobe, le direttive block istanziano la classe specificata indipendentemente dal fatto che sia una classe “Block” o meno. A questo punto, possiamo quindi creare oggetti arbitrari.

Fase 3: trasformare la SSTI in RCE

A questo punto abbiamo 1) codice PHP in un file di log e 2) una SSTI in grado di istanziare classi arbitrarie. Per collegare i due elementi, dobbiamo istanziare una classe in grado di eseguire il codice che abbiamo inserito nel file di log nella fase 1. È qui che diventa importante Magento\Email\Block\Adminhtml\Template\Preview, inserito in precedenza. È una classe che può eseguire il rendering di template a partire dai parametri di query “text”, “styles” e “type”. Invieremo quindi una richiesta con i seguenti parametri di query (con codifica URL):

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

styles (in formato di parametro di query codificato in 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

In questa richiesta, usiamo contemporaneamente anche la mutazione graphql handlePayflowProResponse per avviare l’elaborazione del modello di email relativo al pagamento non riuscito. Questo innesca la seguente sequenza di eventi:

1. Il blocco “Preview” inserito in precedenza viene elaborato durante l’elaborazione del modello di email, causando la creazione dell’altro blocco del nostro payload, “ColumnSet”, a partire dal parametro di query “text”.

2. ColumnSet riceve l’array “styles” come argomenti e chiama una “UrlGeneratorFactory” con il valore “Aws\S3\S3Client” che abbiamo fornito per generatorClass.

3. Durante la costruzione di S3Client, viene creato l’oggetto “Magento\Setup\Module\Di\Code\Scanner\ArrayScanner” da noi fornito, che chiama il metodo “collectEntities”

4. collectEntities chiama “include” sul valore “first” che abbiamo fornito nell’array styles, ovvero il nostro file di log contenente il codice dannoso. 

5. Il codice che abbiamo inserito nel file di log viene eseguito durante l’operazione di include (a causa della sequenza <?= senza escape) e ora abbiamo l’esecuzione di codice remoto (RCE). 

È da qui che deriva il nome «Style Smuggler». Sfrutta il parametro “styles” usato dalla classe Preview per introdurre le informazioni aggiuntive sul gadget necessarie per eseguire il codice. È inoltre importante notare che potrebbero esistere altri gadget utilizzabili nella codebase di Magento e che abbiamo individuato almeno una variante che usa un payload diverso dal blocco “Preview”.

Template Nuclei

Per aiutare la community a verificare la presenza di istanze vulnerabili a Style Smuggler, abbiamo inviato un template Nuclei per CVE-2026-75650 al repository ufficiale nuclei-templates. Pur avendo sviluppato noi il template, abbiamo aspettato a inviarlo finché Graycore non ha pubblicato un’analisi dettagliata della vulnerabilità e Sansec non ne ha preso atto, per evitare di divulgare informazioni sulla vulnerabilità fino ad allora tenute riservate. Abbiamo testato il template in locale su Magento v2.4.9 e v2.4.7-p2, per assicurarci che funzionasse correttamente su più versioni.

Patch virtuale per CVE-2026-75650

Fastly ha rilasciato una patch virtuale per CVE-2026-75650 che copre ogni fase dell’exploit Style Smuggler. Questo offre una difesa in profondità contro le varianti che interessano una parte della catena e dà agli operatori il tempo di applicare le patch ai propri sistemi. Questa patch virtuale è poco soggetta a falsi positivi durante le normali operazioni, inclusi gli aggiornamenti dei template da parte degli amministratori, e non è correlata ai falsi positivi descritti in altri articoli.