CVE-2026-75650: Adobe risolve la vulnerabilità Magento Zero-Day attivamente sfruttata per distribuire backdoor

Adobe ha rilasciato un aggiornamento di sicurezza urgente che affronta una vulnerabilità di massima gravità in Adobe Commerce e Magento Open Source che gli attaccanti stanno già sfruttando nel mondo reale. Identificata come CVE-2026-75650 e valutata 10.0 nella scala CVSS, la falla consente l’esecuzione remota di codice non autenticato su server e-commerce vulnerabili.

La vulnerabilità, soprannominata StyleSmuggler dalla compagnia di sicurezza e-commerce Sansec, sfrutta la funzionalità di elaborazione del template di Magento per iniettare ed eseguire codice PHP dannoso. Gli attacchi sono stati confermati per la prima volta il 4 settembre 2026, diversi giorni prima che Adobe rilasciasse il suo hotfix di emergenza il 7 settembre.

Gli attori delle minacce hanno già utilizzato la zero-day per distribuire una backdoor Linux basata su Rust e, in attacchi separati, una web shell PHP in grado di eseguire comandi PHP arbitrari. Poiché lo sfruttamento non richiede alcun account Magento valido o interazione dell’utente, i negozi esposti a internet che eseguono versioni vulnerabili devono essere trattati come obiettivi ad alta priorità per la patching e l’indagine retrospettiva.

Analisi di CVE-2026-75650

Adobe classifica la vulnerabilità come CWE-1336: Neutralizzazione Impropria di Elementi Speciali Usati in un Motore di Template. Il suo vettore CVSS indica uno sfruttamento basato su rete, bassa complessità di attacco, nessun privilegi e nessuna interazione utente, con potenzialmente alto impatto su confidenzialità, integrità e disponibilità.

I dettagli più importanti per CVE-2026-75650 riguardano il modo in cui Magento trasforma i dati controllati dall’attaccante in PHP eseguibile durante il normale processamento dell’applicazione. StyleSmuggler sfrutta direttive di template e funzionalità di iniezione di dipendenze interne invece di fare affidamento su un’estensione malevola o un account amministratore.

A livello generale, l’attacco noto segue due stadi. Innanzitutto, il contenuto PHP controllato dall’attaccante viene scritto in un file a cui Magento può accedere in seguito, come un log di applicazione o un report. Una seconda richiesta causa quindi che la catena di elaborazione del template di Magento raggiunga la funzionalità dello scanner di iniezione di dipendenze che carica il file avvelenato utilizzando PHP include o require_once. Poiché queste funzioni interpretano PHP invece di leggere semplicemente il file, il codice controllato dall’attaccante viene eseguito sul server.

Sansec descrive un altro aspetto osservabile della catena: gli attaccanti innescano deliberatamente la normale Email di Promemoria di Transazione di Pagamento Fallita di Magento. Il codice dannoso viene eseguito mentre Magento rende il template, quindi un cliente o amministratore non ha bisogno di aprire l’email. L’exploit può riuscire anche quando la consegna effettiva dell’email fallisce.

Contatta Vendite

CVE-2026-75650 interessa i seguenti rami di Adobe Commerce secondo il bollettino di emergenza di Adobe:

• 2.4.9-2026-ago e versioni precedenti
• 2.4.8-2026-ago e versioni precedenti
• 2.4.7-2026-ago e versioni precedenti
• 2.4.6-2026-ago e versioni precedenti
• 2.4.5-2026-ago e versioni precedenti
• 2.4.4-2026-ago e versioni precedenti

Le versioni di Adobe Commerce B2B interessate includono:

• 1.5.3-2026-ago e versioni precedenti
• 1.5.2-2026-ago e versioni precedenti
• 1.4.2-2026-ago e versioni precedenti
• 1.3.4-2026-ago e versioni precedenti
• 1.3.3-2026-ago e versioni precedenti

I rami di Magento Open Source fino a 2.4.9-2026-ago sono anche coperti dal bollettino di Adobe.

Sansec ha riprodotto indipendentemente l’intera catena di attacco non autenticato su installazioni pulite di Magento Open Source 2.4.7, 2.4.8 e 2.4.9. Il suo primo cliente compromesso confermato stava eseguendo Magento 2.4.6-p15 con entrambi gli aggiornamenti di sicurezza di luglio e agosto applicati, dimostrando che i sistemi considerati completamente patchati prima del 7 settembre erano ancora vulnerabili alla zero-day.

Una volta ottenuta l’esecuzione remota del codice, la compromissione si estende oltre Magento stesso. La prima campagna osservata ha distribuito un piccolo impianto Linux basato su Rust che stabiliva la persistenza e comunicava con l’infrastruttura dell’attaccante mascherandosi come attività di sistema legittima.

Le prime versioni si mascheravano come un processo lavorativo del kernel chiamato:

Le build successive adottavano nomi come:

fc-cache

e:

chronyd

La variante fc-cache si archiviava sotto ~/.cache/fontconfig/fc-cache, aggiungeva un’entrata cron per riavviarsi due volte all’ora e utilizzava il traffico della porta UDP 123 progettato per somigliare alle comunicazioni NTP. Sansec ha riferito che i domini correlati sono risolti a 185.157.160.251 dal 7 settembre.

Un altro attaccante è stato osservato abusare della stessa vulnerabilità per distribuire un piccolo dropper PHP. Quel payload ha creato una web shell PHP nascosta sotto un percorso che somigliava a:

pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php

La shell normalmente restituiva una risposta HTTP 404, ma le richieste contenenti l’intestazione richiesta X-Cache-Token potevano fornire codice PHP tramite un parametro POST per l’esecuzione.

Queste osservazioni mostrano che StyleSmuggler non è legato a una singola famiglia di malware o attore di minacce. Molti avversari possono usare indipendentemente la RCE sottostante per distribuire i loro strumenti di persistenza e post-compromissione preferiti.

Sansec ha registrato la prima sfruttamento confermata il 4 settembre alle 22:20 UTC. Un altro server Magento indagato da Disrex è stato compromesso circa 50 minuti dopo. Adobe ha rilasciato il bollettino APSB26-146 e l’hotfix di emergenza ufficiale il 7 settembre, confermando che lo sfruttamento era già in corso nel mondo reale.

Sansec e Disrex hanno pubblicato estese informazioni tecniche sulla catena sottostante ma hanno intenzionalmente trattenuto una richiesta completamente armata che renderebbe lo sfruttamento facile da riprodurre.

Utile Gli IOC di CVE-2026-75650 includono processi e file sospetti associati all’impianto Rust, file PHP insoliti sotto le directory media di Magento, attività di Promemoria di Transazione di Pagamento Fallita inaspettata e l’infrastruttura identificata da Sansec. I difensori dovrebbero anche cercare contenuti malevoli in report o log anziché limitare le indagini al webroot di Magento.

Mitigazione di CVE-2026-75650

Adobe ha classificato APSB26-146 come Priorità 1 e istruisce i clienti interessati a applicare immediatamente l’hotfix dedicato VULN-39341 . Il pacchetto di patch ufficiale è distribuito tramite il repository Magento di Adobe per le versioni Commerce e Magento Open Source interessate.

Adobe istruisce ulteriormente i clienti a ruotare le loro chiavi di crittografia dopo aver applicato l’hotfix. Questo è particolarmente importante per i negozi che sono stati esposti prima del 7 settembre poiché l’esecuzione arbitraria di codice di successo potrebbe aver consentito agli attaccanti di accedere ai segreti dell’applicazione e alla configurazione sensibile sul lato server.

Il rilevamento di CVE-2026-75650 dovrebbe quindi iniziare con tre domande:

1. Il negozio era accessibile da internet tra il 4 settembre e l’installazione dell’hotfix di Adobe?
2. VULN-39341 è stato applicato con successo?
3. Ci sono segni che sono stati lanciati processi PHP o nativi prima della correzione?

Per rilevare lo sfruttamento di CVE-2026-75650 o l’attività post-compromissione, i team di sicurezza dovrebbero cercare:

• Ritmi inaspettati di email di Promemoria di Transazione di Pagamento Fallita
• Contenuto PHP sospetto nei log di Magento o in file sotto var/report/
• File di report contenenti stringhe x_trace_ insolite
• Processi che si mascherano come [kworker/u:8:0], fc-cache o chronyd
• ~/.local/share/.gvfsd/ o ~/.cache/fontconfig/fc-cache
• Job cron sospetti che riavviano binari sconosciuti
• File PHP inaspettati sotto pub/media/
• Web shell sotto pub/media/catalog/product/cache/
• Traffico in uscita verso infrastruttura StyleSmuggler nota
• Comunicazioni UDP/123 anormali dall’host dell’applicazione Magento
• Richieste HTTP inaspettate che coinvolgono comportamenti di elaborazione del template insoliti
• Nuovi utenti dell’applicazione, credenziali modificate o configurazione del server alterata a seguito di attività web sospetta

Gli amministratori non dovrebbero supporre che l’eliminazione di un file sospetto dalla directory di Magento rimuova la compromissione. Negli incidenti indagati, il malware si è spostato fuori dal webroot, ha creato una persistenza basata su cron, ha continuato ad eseguire da file eliminati e ha potuto ricreare parti della sua persistenza dopo la rimozione.

Il processo di mitigazione di CVE-2026-75650 dovrebbe quindi includere una risposta agli incidenti per i negozi che erano pubblicamente raggiungibili prima della patch. Se vengono scoperti indicatori di compromissione, isolare l’host, preservare le prove forensi, terminare i processi dannosi, identificare i meccanismi di persistenza, esaminare le modifiche al filesystem e ruotare credenziali e segreti accessibili dal server compromesso.

Particolare attenzione dovrebbe essere prestata a:

• Credenziali amministrative di Magento
• Chiavi di crittografia di Adobe Commerce
• Credenziali del database
• Segreti API e di integrazione
• Credenziali di pagamento e di servizi di terze parti
• Credenziali SSH
• Token cloud o hosting accessibili dall’host dell’applicazione

I team di sicurezza dovrebbero anche convalidare l’integrità dei file e delle estensioni dell’applicazione Magento e indagare sull’attività di rete in uscita per segni che un impianto abbia comunicato con infrastruttura di comando e controllo esterna.

Poiché i primi attacchi StyleSmuggler sono avvenuti prima che fossero disponibili patch ufficiali o firme di rilevamento pubbliche, semplicemente confermando che un negozio è ora aggiornato non stabilisce che non sia mai stato compromesso. Qualsiasi sistema vulnerabile esposto a internet operativo durante la finestra zero-day del 4–7 settembre merita una revisione storica.