Adobe corregge StyleSmuggler: CVE-2026-75650 vale 10.0 ed è già sfruttata

🛡️ Executive Summary

• Adobe assegna a StyleSmuggler CVE-2026-75650, punteggio CVSS 10.0 e priorità 1, confermando ufficialmente lo sfruttamento in the wild.
• Il fix arriva come hotfix VULN-39341 per Adobe Commerce e Magento Open Source dalla serie 2.4.4 alla 2.4.9.
• Applicare la patch non basta sui server già colpiti: Adobe chiede rotazione delle chiavi e delle credenziali protette, oltre alla ricerca delle backdoor.

Adobe ha pubblicato la correzione urgente per StyleSmuggler, la zero-day di Magento Open Source e Adobe Commerce sfruttata dal 4 settembre per installare backdoor Linux e web shell PHP sui negozi online. La vulnerabilità è ora identificata come CVE-2026-75650, riceve il massimo punteggio CVSS 10.0 e il bollettino APSB26-146 ha priorità Adobe 1. L’azienda conferma inoltre ufficialmente lo sfruttamento in the wild, trasformando quella che fino a poche ore prima era una scoperta indipendente di Sansec in un’emergenza riconosciuta dal vendor. La correzione viene distribuita come hotfix VULN-39341, non come una normale release completa, e deve essere accompagnata da verifiche forensi e rotazione delle credenziali.

CVE-2026-75650 consente RCE senza autenticazione

Il bollettino ufficiale APSB26-146 pubblicato da Adobe classifica CVE-2026-75650 come una vulnerabilità di Improper Neutralization of Special Elements Used in a Template Engine, corrispondente a CWE-1336. Lo sfruttamento consente esecuzione arbitraria di codice da remoto senza autenticazione, senza privilegi preliminari e senza interazione dell’utente. Il vettore CVSS AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H spiega il punteggio massimo: l’attaccante può raggiungere l’installazione attraverso la rete e ottenere impatto completo su confidenzialità, integrità e disponibilità. Sono interessate Adobe Commerce dalla linea 2.4.4 alla 2.4.9, Adobe Commerce B2B dalla 1.3.3 alla 1.5.3 e Magento Open Source dalla 2.4.6 alla 2.4.9 nelle versioni elencate dal vendor, mentre Sansec ha verificato che il problema riguarda in pratica l’intero ramo corrente da 2.4.4 a 2.4.9. Il dato chiude definitivamente il primo capitolo della zero-day StyleSmuggler scoperta mentre comprometteva negozi Magento già aggiornati.

Adobe distribuisce VULN-39341 invece di una release completa

La correzione arriva attraverso VULN-39341, un hotfix separato che i merchant devono applicare senza attendere il normale ciclo di aggiornamento. Nelle istruzioni urgenti pubblicate su Adobe Experience League Adobe indica esplicitamente che il patch deve essere applicato agli ambienti Commerce Cloud, on-premises e Magento Open Source interessati. L’hotfix è stato testato sulle release 2026-aug di Adobe Commerce 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8 e 2.4.9, oltre alle versioni B2B compatibili. Le versioni precedenti all’interno degli stessi rami risultano vulnerabili, ma Adobe avverte che la compatibilità della correzione non è stata verificata ufficialmente su tutte le build più vecchie. Sansec indica il pacchetto VULN-39341-composer-patches.zip, distribuito attraverso il repository Magento, e suggerisce di verificare successivamente lo stato con gli strumenti magento-patches. Per gli amministratori questo significa non poter considerare sufficiente la semplice presenza delle patch di luglio o agosto: la prima vittima analizzata utilizzava 2.4.6-p15 completamente aggiornata prima dello sfruttamento.

Leggi anche: StyleSmuggler evolve con chronyd, traffico NTP camuffato e una seconda web shell PHP

Adobe conferma lo sfruttamento che Sansec osservava dal 4 settembre

Il cambio più importante rispetto alle prime ore dell’incidente riguarda l’attribuzione ufficiale dello stato di exploit. Adobe scrive ora esplicitamente di essere a conoscenza di CVE-2026-75650 sfruttata in the wild contro merchant Adobe Commerce. Sansec aveva individuato il primo attacco confermato il 4 settembre alle 22:20 UTC, aveva riprodotto la catena su installazioni pulite il giorno successivo e pubblicato le prime regole di protezione poche ore dopo. L’analisi tecnica aggiornata di Sansec ricostruisce una catena in due passaggi: l’attaccante inserisce codice PHP malevolo all’interno del sistema di template utilizzando le proprietà styles, poi forza Magento a renderizzare il contenuto avvelenato attraverso il meccanismo delle email relative ai pagamenti falliti. L’esecuzione avviene quindi sul server senza che il destinatario debba aprire alcun messaggio. La tecnica spiega perché alcuni merchant abbiano osservato improvvisi Payment Transaction Failed Reminder contemporaneamente alla compromissione, anche se l’email da sola non costituisce un indicatore certo perché può essere generata anche da normali pagamenti rifiutati.

La patch chiude il vettore ma non elimina chronyd e le web shell già installate

L’arrivo dell’hotfix non risolve automaticamente i server compromessi prima dell’aggiornamento. Nel giro di tre giorni gli operatori hanno già cambiato più volte payload e persistenza. Le prime installazioni lanciavano una backdoor mascherata come [kworker/u:8:0]; il 6 settembre è comparsa la variante fc-cache 2.1.4, mentre il 7 settembre l’implant è diventato chronyd 2.1.5, con traffico di comando e controllo camuffato da NTP sulla porta UDP 123. Nello stesso giorno Sansec ha individuato un secondo attore indipendente che utilizzava StyleSmuggler per installare una web shell PHP dentro pub/media/catalog/product/cache, dimostrando che la stessa zero-day era già stata adottata da più operatori. È questo il motivo per cui la seconda fase della campagna Magento richiede un’indagine forense anche dopo l’applicazione di VULN-39341: una patch blocca un nuovo ingresso, ma lascia intatti processi, cron, file PHP e credenziali eventualmente sottratti prima della correzione.

Adobe chiede di ruotare chiave di cifratura e credenziali protette

La misura più significativa nelle istruzioni Adobe riguarda proprio la rotazione delle chiavi. Il vendor chiede ai merchant di applicare VULN-39341 e quindi ruotare la encryption key dell’installazione, insieme alle credenziali che quella chiave proteggeva. Sansec specifica che il perimetro comprende password amministrative, token di integrazione REST/SOAP/GraphQL, OAuth client secret, credenziali delle API dei gateway di pagamento, credenziali del database, chiavi SSH e deploy key, oltre alle API key delle estensioni di terze parti. Il passaggio deve avvenire alla fonte: sostituire soltanto il valore memorizzato dentro Magento non revoca automaticamente una chiave o un segreto già letto dall’attaccante. Questa indicazione conferma l’impatto potenziale della RCE: una volta ottenuta l’esecuzione nel contesto applicativo, l’avversario può tentare di raggiungere non soltanto il database dell’e-commerce, ma l’intero insieme dei segreti utilizzati dal negozio per comunicare con servizi esterni.

La ricerca degli indicatori resta obbligatoria dopo VULN-39341

Gli amministratori devono quindi combinare patching e threat hunting. Sansec continua a indicare la ricerca di processi con nomi kworker, fc-cache e chronyd in contesti anomali, file sotto ~/.local/share/.gvfsd, ~/.cache/fontconfig, directory temporanee .kw_*, .fc-* e .chrony-*, oltre ai messaggi crontab command not allowed nei log. Per la seconda catena occorre controllare soprattutto la presenza di file PHP sotto pub/media, dove codice eseguibile non dovrebbe normalmente comparire. Un altro indicatore è costituito dai marker x_trace_ nei report Magento. Nessuno di questi controlli deve essere considerato esaustivo perché almeno due operatori hanno già utilizzato la vulnerabilità e l’infrastruttura è cambiata rapidamente. La situazione segue un modello già osservato in altre campagne contro applicazioni Web esposte: una volta resa pubblica l’esistenza di una RCE affidabile, gruppi differenti possono convergere sullo stesso prodotto e installare web shell indipendenti.

Continua con:

• Adobe Commerce aveva già ricevuto patch urgenti per vulnerabilità critiche ad agosto
• Chrome, WordPress, Plex e altri prodotti sotto attacco richiedono patch e verifica delle compromissioni

StyleSmuggler passa da zero-day sconosciuta a incidente da gestire

Con APSB26-146, StyleSmuggler cambia natura operativa. Fino al 7 settembre gli amministratori dovevano mitigare una vulnerabilità senza CVE e senza patch ufficiale, facendo affidamento sulle regole di Sansec o sulla disabilitazione temporanea di GraphQL. Ora esiste una correzione Adobe, una classificazione CVE-2026-75650, un punteggio CVSS 10.0 e la conferma ufficiale dello sfruttamento attivo. Questo riduce l’incertezza sul vettore, ma aumenta la responsabilità degli operatori: ogni installazione vulnerabile che rimane esposta dopo la disponibilità dell’hotfix offre agli attaccanti una finestra ormai evitabile. Il problema più difficile riguarda invece i negozi compromessi tra il 4 settembre e l’applicazione del patch. Per questi sistemi l’obiettivo non è soltanto “aggiornare Magento”, ma stabilire se l’attaccante abbia già lasciato persistenza, letto segreti o installato una seconda backdoor. La fase zero-day è terminata. Quella di incident response, per molti merchant, potrebbe essere appena iniziata.