stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) toolkit IOC per Magento Open Source e Adobe Commerce. Rileva negozi compromessi, implant Rust, web shell PHP, artefatti di persistenza e indicatori noti di compromissione.

Copertura della patch ufficiale di Adobe — controlla questo prima di presumere di essere al sicuro

Se sei su una versione più vecchia e non supportata, Adobe non ti sta fornendo una correzione anche se sei altrettanto sfruttabile. Vedi docs/PATCHING.md per le tue opzioni.

Queste informazioni cambiano rapidamente. Verifica incrociata con le fonti primarie prima di agire: l'advisory di Sansec e il bollettino di Adobe. Vedi docs/TIMELINE.md per un registro continuo e cita le tue fonti quando aggiorni qualcosa qui.

Cos'è realmente StyleSmuggler

Il parametro GraphQL styles di Magento e il suo scanner di file basato su dependency-injection vengono abusati come una primitiva di esecuzione differita basata su file in due fasi, piuttosto che come un singolo punto di iniezione evidente:

1. Avvelenamento. I dati controllati dall'attaccante raggiungono un file di log o di report generato da Magento (var/log/system.log tramite un codice store non valido che Magento registra testualmente, o var/report/<hash>), introdotti di nascosto tramite il parametro GraphQL styles[], un header di richiesta mutato o (per il secondo attaccante non correlato sotto) l'header Store:.
2. Detonazione. L'attaccante attiva l'email standard di Magento "Promemoria pagamento transazione non riuscita". Il rendering di quella email (il percorso getProcessedTemplate di Magento) percorre un percorso di codice che consente allo scanner DI/codice di Magento di fare include() del file avvelenato, eseguendo il PHP dell'attaccante. Non devi aprire l'email — il rendering lato server è sufficiente — e la catena può attivarsi anche quando la consegna dell'email stessa fallisce.

Un segnale di allarme precoce facile, senza strumenti: un'email "Promemoria pagamento transazione non riuscita" illeggibile nella tua casella di posta con tag {{var ...}} grezzi e non renderizzati e un indirizzo cliente che termina in .invalid. Questo è spesso il primo segno visibile, prima che qualcuno controlli un log.

Gli aggiornamenti di Sansec hanno confermato un secondo percorso di sfruttamento indipendente per la stessa campagna con implant Rust: anche gli store che avevano spostato l'archiviazione delle sessioni da Redis al database sono stati comunque compromessi — il secondo tentativo dello stesso operatore è riuscito secondi dopo usando un file caricato tramite la funzionalità opzioni personalizzate del cliente di Magento. Spostare l'archiviazione delle sessioni non è una soluzione di per sé.

Separatamente, il 7 settembre, Sansec ha trovato un attaccante completamente non correlato che usa lo stesso identico punto di ingresso di StyleSmuggler per un payload molto più semplice: una web shell PHP lasciata nella cache delle immagini dei prodotti di Magento (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), preceduta da una sonda di ricognizione che nasconde il suo payload nell'header HTTP Store: ed esfiltra i suoi risultati tramite DNS piuttosto che una risposta HTTP. Questo è "tooling pronto all'uso", secondo Sansec — non una campagna sostenuta — ma significa che un singolo host vulnerabile può portare due intrusioni non correlate attraverso un'unica falla. Pulire l'implant Rust non significa che il tuo store sia pulito.

Anche l'implant Rust si è evoluto: la build originale che si mascherava da [kworker/u:8:0] (4 set) è stata seguita da una build v2.1.4 che si mascherava da fc-cache (6 set) che fa beaconing camuffato da traffico NTP, e poi da un redeploy v2.1.5 che si mascherava da chronyd (7 set) dello stesso implant, stesso ID agente — prova che l'attaccante sta iterando attivamente per eludere qualsiasi rilevamento tu pubblichi. Sansec dichiara di non aver ancora visto prove che questo implant sia stato armato oltre la persistenza/ricognizione — non leggerlo come rassicurazione dato il web shell funzionante dell'attaccante non correlato sullo stesso percorso di accesso.

Vedi docs/FAQ.md per risposte rapide, docs/VULNERABILITY.md per l'analisi tecnica completa e le fonti, docs/PATCHING.md per applicare la correzione ufficiale di Adobe, e docs/INCIDENT_RESPONSE.md per cosa fare se lo scanner trova qualcosa.

Avvio rapido

1. Applica la patch, se la tua versione è coperta:

2. Scansiona per compromissioni esistenti indipendentemente dallo stato della patch — la patch ferma il nuovo sfruttamento, non pulisce una backdoor o una web shell esistente:

Oppure la versione Python per output strutturato (JSON), ad es. per alimentare un SIEM:

Entrambi gli script sono sola lettura per impostazione predefinita — rilevano e riportano, non uccidono processi o eliminano file a meno che tu non passi --remediate, perché una pulizia prematura distrugge le prove forensi (vedi docs/INCIDENT_RESPONSE.md).

Cosa controlla lo scanner

• Artefatti noti di persistenza nel filesystem in tutte e tre le build osservate dell'implant Rust:
  • Build [kworker/u:8:0]: ~/.local/share/.gvfsd/gvfsd-user, i suoi file di lock, /tmp/.kw_*, /tmp/.gvfsd_*
  • Build fc-cache v2.1.4 (6 set): ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • Build chronyd v2.1.5 (7 set): /tmp/.chrony-<8hex>/chronyd
• Le voci crontab auto-ripristinanti che l'implant scrive direttamente nello spool di cron — ogni 5 minuti per la build gvfsd-user, due volte all'ora (13,43 * * * *) per fc-cache
• Un processo mascherato chiamato [kworker/u:8:0], fc-cache o chronyd che non è di proprietà di root (o, per fc-cache/chronyd, non corrisponde al binario di sistema reale)
• SHA-256 dei binari su disco e dell'immagine live /proc/<pid>/exe (i due possono differire — è stato osservato che l'implant si aggiorna in memoria)
• File di log/report avvelenati (var/log/system.log, var/report/) per PHP iniettato, le due forme note di header trigger (X-TRACE-<10hex> e X-<12hex>), e i marcatori di campagna del secondo attaccante non correlato (ss5_/ss6_<hex>) e il dominio canary DNS (oast.site)
• Marcatori di risposta di prova di esecuzione (MG<20hex>::...::/MG<20hex>) lasciati nei log quando il payload è effettivamente eseguito
• File PHP sotto pub/media — che non dovrebbero mai contenere PHP eseguibile su uno store Magento configurato correttamente — che corrispondono al pattern di drop della web shell del secondo attaccante
• Connessioni stabilite verso gli host C2/download pubblicati — inclusi il beaconing a forma di NTP della build fc-cache/chronyd verso ntp.timesync.to:123/UDP (e fallback), e le sue chiamate HTTP semplici a servizi pubblici di lookup IP
• Conteggi anomali di connessioni Redis locali (è stata osservata raccolta di sessioni interamente su 127.0.0.1:6379, con zero traffico C2 in uscita — una rete silenziosa non è una rete pulita) — e nota che spostare le sessioni da Redis da solo non chiude il secondo vettore di sfruttamento basato su caricamento file

Elenco completo degli indicatori con fonti: iocs/.

Patch e mitigazione

1. Applica l'hotfix ufficiale di Adobe (VULN-39341 / APSB26-146) se la tua versione è coperta — vedi docs/PATCHING.md per gli identificativi, dove ottenerlo e come applicarlo. Questa è ora la priorità, prima delle mitigazioni provvisorie sotto.
2. Se non puoi applicare la patch immediatamente, o la tua versione non è coperta, usa le mitigazioni provvisorie in mitigations/:
   • Blocca o limita il percorso di consegna di styles[] di GraphQL (nginx / Apache)
   • Blocca l'esecuzione di PHP sotto pub/media/pub/static (nginx / Apache) — difesa mirata contro la tecnica della web shell del secondo attaccante non correlato
   • Regole ModSecurity per l'ispezione del corpo POST e fail2ban come rete di sicurezza reattiva
   • Vedi mitigations/README.md per i limiti di ambito — nessuna di queste chiude il vettore delle opzioni personalizzate del cliente o la consegna tramite header Store: del secondo attaccante.
3. Esegui lo scanner di compromissione indipendentemente dallo stato di patch/mitigazione. Patch e mitigazioni fermano lo sfruttamento nuovo; nessuna delle due pulisce una backdoor o una web shell già rilasciata.
4. Se lo scanner trova qualcosa, tratta l'host come completamente compromesso, non solo "backdoor presente". L'esecuzione di codice come utente del sito espone tutto ciò che quell'utente può leggere, a partire da app/etc/env.php. Come minimo, dopo il contenimento: svuota l'archiviazione delle sessioni (Redis e/o DB), ruota la crypt/key di Magento, tutte le password admin (e invalida le sessioni admin esistenti), la password del database, ogni chiave API del fornitore di pagamento e altra credenziale di integrazione in env.php, e qualsiasi chiave SSH/deploy che l'utente del sito poteva leggere. Controlla anche la tabella admin_user per un account rogue e le directory pub/media/ / pub/static/ / dei temi per web shell rilasciate — sia quelle dell'implant Rust sia quelle del secondo attaccante non correlato — prima di considerare uno store pulito. Passaggi ordinati completi: docs/INCIDENT_RESPONSE.md.

Struttura del repository

Termini cercati di frequente

CVE-2026-75650, APSB26-146, VULN-39341, zero-day Magento 2026, zero-day Adobe Commerce, patch StyleSmuggler, vulnerabilità GraphQL Magento, RCE parametro styles Magento, malware gvfsd-user, backdoor Magento fc-cache, malware Magento chronyd, malware processo kworker Magento, dirottamento sessione Redis Magento, RCE non autenticato Magento settembre 2026, exploit Magento 2.4.9, rimozione backdoor Adobe Commerce, web shell Magento pub/media, eComscan StyleSmuggler, Sansec Shield StyleSmuggler.

Fonti e provenienza

Ogni indicatore in questo repository risale a una fonte pubblicata e citata — principalmente l'advisory di Sansec (aggiornata almeno fino al 2026-09-07 20:50 UTC), il bollettino APSB26-146 di Adobe e analisi di incident response della community da parte di responder che hanno gestito infezioni live. Vedi la citazione in fondo a ogni file in iocs/.

Non trattare nulla qui come esaustivo o definitivo. Gli IOC (header trigger, stringhe user-agent, travestimenti dell'implant e ora i marcatori di campagna di un secondo attaccante) sono già cambiati più volte entro giorni dalla divulgazione; aspettati che cambino di nuovo. Abbina forme e comportamenti, non solo stringhe letterali, ovunque gli script te lo consentano.

Contribuire

Hai visto una variante, un nuovo hash, un nuovo indirizzo sorgente o un falso positivo? Apri un issue o una PR con ciò che hai osservato e come lo hai osservato. Per favore:

• Oscura i dettagli identificativi della tua organizzazione prima di condividere.
• Non pubblicare payload di exploit o richieste trigger funzionanti qui — solo indicatori e logica di rilevamento.
• Segnala la vulnerabilità sottostante stessa a Sansec e ad Adobe PSIRT, non a questo repository.

Licenza

MIT per il codice in questo repository (vedi LICENSE). I dati degli indicatori sono forniti "così come sono" per uso difensivo, con le fonti annotate ovunque.

Disclaimer

Questo è tooling difensivo non ufficiale costruito dalla community, non un prodotto Adobe o Sansec, e non è affiliato a nessuno dei due. È fornito senza garanzia. La patch ufficiale di Adobe (APSB26-146) è stata rilasciata, ma la copertura è limitata a versioni di prodotto specifiche — controlla il bollettino di sicurezza di Adobe direttamente prima di presumere che la tua installazione sia coperta o corretta.