StyleSmuggler: lo zero-day Magento (CVE-2026-75650) che apre gli store

Il 4 settembre 2026 alle 22:20 UTC, Sansec ha osservato uno store Magento perfettamente aggiornato venire compromesso da remoto da un attaccante che non aveva bisogno di credenziali, né di una sessione, né di alcuna interazione dell'utente. L'hotfix d'emergenza di Adobe non esisteva ancora — è arrivato tre giorni dopo, il 7 settembre alle 20:20 UTC. Tutto ciò che sta in mezzo è stato uno zero-day in azione contro una delle piattaforme e-commerce più diffuse in rete. La vulnerabilità è oggi CVE-2026-75650, CVSS 10.0, e ha un nome: StyleSmuggler.

Il punto interessante non è che Magento avesse l'ennesimo bug critico — di quelli ne ha una lunga storia. È ciò che gli attaccanti hanno lasciato dietro di sé: un impianto Rust che si rinomina chronyd, si nasconde nella cache di fontconfig e chiama casa con traffico modellato per sembrare pacchetti di sincronizzazione oraria NTP. È malware progettato apposta perché l'host compromesso non possa vederlo. Il che significa che l'unico posto in cui è onesto è sul filo della rete.

Cosa fa davvero StyleSmuggler (CVE-2026-75650)

Magento genera gran parte dei suoi contenuti di email e template attraverso un sistema di layout che risolve riferimenti a oggetti a runtime. StyleSmuggler abusa delle proprietà styles del motore di template per far passare PHP oltre le protezioni che Adobe aveva aggiunto dopo precedenti bug di template-injection — da qui il nome. L'exploit lavora in due fasi, e la seconda è quella che lo rende cattivo:

1. Iniezione. L'attaccante invia una richiesta che spinge Magento a scrivere PHP controllato dall'attaccante dentro un report di errore — un artefatto dall'aspetto innocuo che la piattaforma genera quando qualcosa va storto.
2. Detonazione. L'attaccante poi innesca una email di pagamento fallito. Il rendering di quella email deserializza ed esegue il template avvelenato, e il PHP iniettato gira come utente del web server. Nessuna autenticazione, nessuna sessione admin — ovunque sia raggiungibile il flusso di checkout, è raggiungibile il bug.

Sono colpiti tutti i rami supportati: Magento Open Source e Adobe Commerce dalla 2.4.4 alla 2.4.9, e Adobe Commerce B2B dalla 1.3.3 alla 1.5.3. Sansec ha confermato exploit funzionanti contro installazioni pulite di 2.4.7, 2.4.8 e 2.4.9 — non è un bug di configurazione che si sistema con un linter. Se il vostro store ha incassato pagamenti questo mese, questo mese era exploitabile.

"Ma noi patchiamo in fretta." Anche la prima vittima lo faceva — girava con l'ultima security release quando è stata colpita il 4 settembre, giorni prima che esistesse una fix. La velocità contro le CVE note non fa nulla contro uno zero-day. La finestra tra il primo sfruttamento e l'hotfix di Adobe è stata di circa 70 ore, e gli attaccanti le hanno usate tutte.

Una backdoor costruita per sembrare il sistema operativo

Una volta ottenuta l'RCE, comincia l'ingegneria interessante. Il payload è un processo Rust in background — Sansec ne ha visto le versioni 2.1.4 e 2.1.5 — e quasi ogni scelta di design serve a non farsi notare:

• Prende in prestito i nomi delle cose di cui vi fidate. I primi campioni comparivano come [kworker/u:8:0] (un thread di kernel worker). Quelli più recenti si sono rinominati fc-cache (fontconfig) e poi chronyd (il demone NTP). In una lista di processi si legge come infrastruttura noiosa.
• Vive dove nessuno guarda. ~/.cache/fontconfig/fc-cache, ~/.local/share/.gvfsd/, /tmp/.chrony-<8hex>/chronyd. Cache utente e directory temporanee che nessun baseline di integrità sorveglia.
• Controlla se lo state guardando. L'impianto legge il proprio TracerPid per rilevare un debugger prima di fare qualsiasi cosa interessante.
• Il suo canale di comando è un travestimento. Il C2 primario è un WebSocket su TLS (99.84.67.186:443, windwsecurity.run:443). Il fallback è la parte astuta: UDP verso la porta 123, la porta NTP, verso host dai nomi da server orario (ntp.timesync.to, time.microsft.run, pool.microsft.studio). Solo i primi quattro byte sono vero header NTP — il resto di ogni pacchetto trasporta un record MessagePack a blocchi con la telemetria dell'host (hostname, utente, versione OS, uso di memoria e disco, se ha i privilegi di root). Un firewall che consente NTP in uscita — quasi ogni firewall — lascia passare l'intero canale.

La persistenza è un insieme di righe cron dall'aria innocua che scattano ogni pochi minuti:

*/5 * * * * <home>/.local/share/.gvfsd/gvfsd-user
13,43 * * * * <home>/.cache/fontconfig/fc-cache
57,27 * * * * /tmp/.chrony-<8hex>/chronyd

Un secondo attore, distinto, si è infilato dallo stesso buco con semplici web shell PHP, protette dietro un header X-Cache-Token e con callback verso un dominio interactsh oast.site. Quando una nuova RCE è pubblica, raramente vi arriva un solo ospite non invitato.

Perché l'host è il posto sbagliato dove guardare

Mettete in fila le tecniche di evasione ed emerge uno schema. Processo travestito da chronyd. File nella cache di fontconfig. Controlli anti-debug. C2 in tunnel dentro NTP. Questo payload è stato costruito da qualcuno che dava per scontato che la vittima usi tooling endpoint e raccolta di log — e ha progettato ogni strato per sopravvivere a entrambi. L'utente del web server che esegue l'exploit può, su molti deployment Magento, raggiungere abbastanza dell'host da manomettere proprio la telemetria che usereste per intercettarlo.

È il modo di fallire ricorrente nelle compromissioni e-commerce: il gestore dello store lo scopre settimane dopo, dalla banca acquirer o da un cliente, che le carte venivano rubate. L'e-skimming in stile Magecart e la cattura di dati di carta lato server sono esattamente ciò in cui una RCE Magento si monetizza, e sull'host sono silenziosi per progetto.

Ma nessuna di quelle tecniche tocca la rete in modo onesto. Il processo chronyd deve comunque aprire un socket verso windwsecurity.run. Il beacon travestito da NTP va comunque verso un ASN con cui questo store non ha mai parlato. I dati di carta rubati devono comunque uscire dall'edificio. Il masquerading inganna una lista di processi; non cambia con chi stai parlando.

Evasione sull'host	Cosa resta visibile sul filo
Rinominato chronyd / fc-cache	Nuova sessione in uscita verso una destinazione mai vista
C2 in tunnel come NTP (UDP/123)	Pacchetti NTP il cui payload non è NTP; volume e cadenza che nessun client reale produce
Nascosto in ~/.cache, anti-debug	Nulla — nascondere file non ha equivalente di rete
Web shell protetta da header segreto	Callback OOB verso un dominio oast.site / interactsh
Manomissione dei log dall'utente web	Staging ed esfiltrazione hanno già attraversato la rete prima che il log venga toccato

L'orologio normativo che fa partire

Se StyleSmuggler ha lasciato uno skimmer su uno store che accetta carte, questo non è solo un incidente — è una violazione di dati di pagamento. Secondo PCI DSS v4.0.1, i requisiti 6.4.3 e 11.6.1 — obbligatori dal 31 marzo 2025 — dovete gestire e rilevare le modifiche non autorizzate agli script e ai contenuti delle pagine di pagamento, proprio perché l'iniezione di uno skimmer emerga. Nella UE, un operatore e-commerce di qualsiasi dimensione coinvolto può inoltre dover fare una notifica ex art. 33 GDPR entro 72 ore e — per gli operatori più grandi — la segnalazione di incidente NIS2. La domanda sulle prove che un auditor o un regolatore fa subito dopo è netta: quando è iniziato, cosa è uscito, e potete dimostrare che ora lo store è pulito? La remediation qui sotto è scritta per rispondere esattamente a questo.

Remediation

Un runbook completo per CVE-2026-75650. Verificate ogni versione e IOC contro il bollettino Adobe APSB26-146 e l'advisory Sansec prima di agire — è un bersaglio in movimento.

1. Sono esposto?

Controllate la vostra versione Magento/Commerce:

php bin/magento --version
# oppure
grep '"version"' composer.lock | grep -i 'magento/product'

Siete nel perimetro se girate Magento Open Source o Adobe Commerce 2.4.4–2.4.9, oppure Adobe Commerce B2B 1.3.3–1.5.3. Poiché gli attacchi sono iniziati prima che la patch esistesse, assumete l'esposizione anche se siete aggiornati — trattate ogni store raggiungibile da internet tra il 4 e il 7 settembre come potenzialmente colpito, e passate al punto 4 (Caccia) a prescindere dallo stato di patch.

2. Patch — la fix esatta

Applicate l'hotfix Adobe VULN-39341 (bollettino APSB26-146), rilasciato il 7 settembre 2026:

# bundle hotfix via composer da Adobe
composer require magento/quality-patches --dev
# applicate, poi confermate che sia registrata:
vendor/bin/magento-patches -n status | grep -E "39341|Status"

La patch non sfratta un impianto atterrato prima della patch stessa. Chiude solo la porta.

3. Non potete patchare in quest'ora? — controlli compensativi

• Virtual patch sul WAF. Bloccate le richieste che innescano la scrittura del report di errore e il percorso di rendering dell'email di pagamento fallito; Sansec Shield ha iniziato a bloccare il 5 settembre alle 07:15 UTC e le sue firme sono un riferimento utile.
• Disabilitate GraphQL se non vi serve — Sansec lo ha raccomandato come mitigazione provvisoria in attesa della fix.
• Filtrate in uscita il canale nascosto. Limitate l'UDP/123 in uscita ai vostri soli server NTP noti e sanzionati. Il C2 travestito da NTP muore nel momento in cui lo store non può raggiungere "server orari" arbitrari.
• Bloccate i C2 noti: 99.84.67.186, windwsecurity.run, ntp.timesync.to, ntp.timesysnc.net (185.157.160.251), time.microsft.run, pool.microsft.studio, ntp.synctime.to, ntp.syncstime.to.

4. Cacciate la compromissione (fatelo anche se avete patchato)

Mappatura MITRE ATT&CK: accesso iniziale T1190 (exploit di applicazione pubblica) → esecuzione T1059 → web shell T1505.003 → persistenza T1053.003 (cron) → masquerading T1036.005 → protocol tunnelling / impersonation T1572 / T1001.003 → discovery T1082.

Processi e persistenza:

# impianto travestito da demone di sistema
ps aux | grep -E 'kworker/u:8:0|fc-cache|chronyd' | grep -vE '\[kworker'
# il vero chronyd sta in /usr/sbin — qualsiasi cosa sotto /tmp o ~/.cache non lo è
ls -la ~/.cache/fontconfig/fc-cache ~/.local/share/.gvfsd/ /tmp/.chrony-* /tmp/.fc-* 2>/dev/null
# cron ostile
crontab -l; ls -la /etc/cron.d/ /var/spool/cron/

Web shell e dropper:

# PHP inatteso sotto la cache media non è mai legittimo
find pub/media/catalog/product/cache/ -name '*.php' -mtime -14
grep -rIl 'X-Cache-Token' pub/media/ app/ 2>/dev/null

Hash SHA256 noti dell'impianto: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7, b79dfdc1eed860e0b76c629d6adfce251db379b0b45a6d728d4ef483f7551420, 4352cabaa451e5a894535fbcc4d46628701303322a13745cb5479d7d0534ae8e. Sulla rete, cercate UDP/123 in uscita verso qualcosa di diverso dai vostri server NTP, e qualsiasi sessione WebSocket/TLS verso gli IP C2 sopra. Passate eComscan per rilevare skimmer e impianti noti.

5. Bonifica + verifica

1. Terminate l'impianto, rimuovete le voci cron e ogni percorso di file sopra, cancellate ogni web shell piantata.
2. Ruotate la chiave di cifratura Magento e tutto ciò che deriva da una RCE completa: password admin, token API, segreti di integrazione, credenziali di database e qualsiasi chiave SSH sull'host. Un attaccante con la chiave di cifratura può forgiare sessioni admin molto dopo che avete patchato — Adobe lo indica esplicitamente.
3. Ri-scansionate gli script delle pagine di pagamento e fatene il diff contro un baseline noto-buono (è il controllo PCI DSS 11.6.1) per confermare che nessuno skimmer sia sopravvissuto.
4. Solo dopo patch + bonifica + rotazione chiavi, confermate lo stato pulito: nessun processo travestito, nessun cron ostile, nessun traffico NTP anomalo in uscita su un intero intervallo di beacon.

Intercettarlo mentre accade

Ogni scelta di design nell'impianto StyleSmuggler è un argomento per guardare la rete invece dell'host. Si rinomina chronyd, si nasconde nelle directory di cache, controlla la presenza di un debugger e tunnela il suo C2 dentro NTP — proprio perché si aspetta che voi stiate leggendo liste di processi e file di log. Ciò che non può falsificare è che uno store che ha sempre e solo ricevuto traffico stia ora aprendo sessioni verso un ASN che non ha mai contattato, con una cadenza che nessun client NTP reale produce.

È esattamente il caso per cui è stato costruito il pilastro AI Traffic Analysis di Zero Hunt. Un modello di deep learning proprietario, addestrato su miliardi di sequenze PCAP, gira sulla GPU dell'appliance a 2.7+ Gbit/s con quattro teste di inferenza parallele — traffico sospetto, classificazione malware, tipo di attacco e fingerprinting applicativo. La testa di fingerprinting non si fida dell'etichetta su un pacchetto: un flusso UDP/123 il cui payload non è NTP, o un "server orario" che nessun client legittimo interrogherebbe con quella cadenza, è un'anomalia nel momento in cui compare — non una voce nel digest SIEM di domani. Il modello osserva lo staging e l'esfiltrazione mentre accadono, l'unico punto in cui una compromissione da carte è ancora economica da fermare. Gira interamente on-prem, senza callback cloud — la stessa postura che il vostro host Magento avrebbe dovuto avere.

La risposta di secondo livello è sul lato offensivo. Il pentest generativo a 10 agenti di Zero Hunt tratta un endpoint di checkout appena esposto come un change-trigger: un nuovo asset sul perimetro fa partire una campagna completa entro l'ora, e gli agenti Exploit e Web scrivono una catena di exploit per singolo target con un LLM locale — non una copia da ExploitDB — per rispondere all'unica domanda che conta durante una finestra zero-day: il mio store è davvero raggiungibile in questo modo, prima che un attaccante me lo dimostri? Ogni tentativo gira in un container effimero, rafforzato con gVisor, che non tocca mai l'host, e ogni finding è firmato ECDSA al momento della scrittura — così, quando l'auditor chiede cosa è uscito e se ora siete puliti, avete una catena di prove, non una stima.

Patchare in fretta è il minimo sindacale. Vedere il beacon che la patch ha mancato è la differenza tra una finestra di 70 ore e una di 70 giorni.