Il 30 marzo 2026 abbiamo vissuto una di quelle giornate in cui ogni minuto conta. Una massiccia ondata di attacchi automatizzati ha colpito centinaia di store Magento nel giro di un’ora, iniettando JavaScript malevolo caricato da un dominio esterno e installando backdoor persistenti sui server compromessi. Quando abbiamo letto l’aggiornamento di Sansec in tempo reale, abbiamo immediatamente avviato l’analisi forense su tutte le installazioni Magento che gestiamo per conto dei nostri clienti.
Cos’e’ PolyShell e perche’ e’ cosi’ pericolosa
La vulnerabilita’, classificata come APSB25-94 e ribattezzata PolyShell dal team Sansec, colpisce ogni versione di Magento Open Source e Adobe Commerce fino alla 2.4.9-alpha2. Il vettore di attacco sfrutta la REST API di Magento nella gestione degli upload di file come parte delle opzioni personalizzate degli articoli nel carrello guest.
Quando un’opzione prodotto e’ di tipo “file”, Magento elabora un oggetto file_info contenente dati codificati in base64 e scrive il risultato nella directory pub/media/custom_options/quote/ sul server, senza validare correttamente il contenuto reale del file ne’ la sua estensione.
Il nome “PolyShell” descrive con precisione la tecnica impiegata: viene caricato un file poliglotta, progettato per passare come immagine GIF o PNG agli occhi del sistema, mentre al suo interno contiene codice PHP eseguibile. Una webshell perfettamente mascherata. A seconda della configurazione del server web, il risultato puo’ essere l’esecuzione remota di codice (RCE) oppure un account takeover tramite stored XSS.
Il dato che rende questa vulnerabilita’ particolarmente grave e’ la sua storia: il codice vulnerabile esiste dalla prima release di Magento 2, rilasciata nel 2015. Undici anni di esposizione potenziale, corretti solo in un ramo pre-release.
La timeline dell’attacco del 30 marzo
La sequenza degli eventi documentata da Sansec e’ precisa e allarmante. L’attivita’ di scanning automatizzato e’ iniziata il 19 marzo 2026, con oltre 50 indirizzi IP coinvolti. Il 30 marzo la catena di exploitation e’ stata completamente automatizzata: gli attaccanti hanno compromesso 214 store in meno di sessanta minuti, iniettando loader JavaScript che puntano al dominio esterno lanhd6549tdhse.top e installando una backdoor denominata accesson.php distribuita in piu’ directory per massimizzare la persistenza.
I payload osservati durante gli attacchi sono di due tipi principali. Il primo e’ una webshell autenticata tramite cookie, che utilizza verifica MD5 con nomi file come index.php, bypass.php e c.php. Il secondo e’ una shell RCE protetta da password con doppia verifica MD5, che passa comandi direttamente alla funzione system() del sistema operativo, distribuita come rce.php o con nomi offuscati tramite Unicode per eludere i scanner di sicurezza di base.
Cosa abbiamo fatto nelle 24 ore successive
Non appena ricevuto l’alert, abbiamo avviato un protocollo di risposta immediata su tutti i siti Magento che gestiamo. Ecco le azioni eseguite in sequenza.
Analisi e scansione forense
Abbiamo verificato la presenza di file sospetti nella directory esposta con il comando:
find pub/media/custom_options/ -type f ! -name '.htaccess'Qualsiasi file con estensione .php, .phtml, .phar o con nome anomalo e’ stato trattato come potenzialmente malevolo e rimosso dopo analisi. Abbiamo inoltre interrogato il database alla ricerca di injection JavaScript nei blocchi CMS, nelle configurazioni di sistema e nei template email.
Verifica della protezione Nginx
Abbiamo verificato che su ogni server fosse presente e attiva la direttiva di blocco sull’endpoint vulnerabile:
location ~* /media/custom_options/ {
deny all;
return 403;
}E’ importante sottolineare che bloccare l’accesso alla directory non impedisce l’upload del file malevolo tramite REST API: impedisce solo la sua esecuzione. Per bloccare completamente il vettore di upload e’ necessario un WAF applicativo in grado di ispezionare il payload delle richieste API.
Deploy del modulo di patch applicativa
In attesa della patch ufficiale Adobe per le versioni di produzione, abbiamo installato su ogni installazione il modulo open source MarkShust_PolyshellPatch, rilasciato da Mark Shust in tempi record dopo la disclosure pubblica. Il modulo agisce direttamente sul codice PHP di Magento, neutralizzando il vettore di upload senza richiedere un aggiornamento completo della piattaforma.
Il ruolo dell’AI nell’incident response
Un aspetto che vale la pena documentare e’ l’impatto concreto che l’utilizzo di Claude (Anthropic) ha avuto sulla velocita’ e qualita’ della nostra risposta. Durante un incidente di sicurezza i compiti si moltiplicano simultaneamente: lettura e interpretazione dei log di accesso, generazione delle query SQL forensi per identificare le injection nel database, analisi degli indicatori di compromissione (IOC), verifica incrociata su server multipli con configurazioni differenti.
Avere un modello AI affiancato durante queste operazioni ha ridotto drasticamente i tempi di analisi. Non si tratta di automazione cieca: si tratta di un supporto alla decisione rapido, contestuale e preciso, che libera il tecnico dalla parte piu’ meccanica del lavoro per concentrarsi sulle scelte critiche.
La situazione delle patch: cosa fare oggi
Al momento della pubblicazione di questo articolo, non esiste una patch isolata per le versioni di produzione di Magento. La correzione di Adobe e’ disponibile solo nel ramo pre-release 2.4.9-alpha3, come documentato da Searchlight Cyber nell’analisi tecnica dettagliata della vulnerabilita’. Le versioni di produzione attualmente supportate — dalla 2.4.4 alla 2.4.8 — restano esposte senza un aggiornamento ufficiale applicabile.
E’ fondamentale non confondere l’advisory APSB25-94, che copre multiple CVE alcune delle quali corrette nei rami di produzione, con la correzione specifica di PolyShell: queste sono cose distinte, e la confusione tra le due potrebbe portare a ritenere di essere protetti quando non lo si e’.
Le azioni da eseguire subito se gestite store Magento
Se gestite uno o piu’ store Magento 2 in qualsiasi versione di produzione, queste sono le azioni da eseguire nell’ordine indicato.
Prima di tutto, verificate la configurazione del vostro server web e assicuratevi che l’accesso alla directory pub/media/custom_options/ sia bloccato. Quindi eseguite una scansione forense della directory alla ricerca di file con estensioni anomale o nomi sospetti. Controllate il database per eventuali injection nei blocchi CMS e nelle configurazioni di sistema. Installate il modulo MarkShust_PolyshellPatch come misura applicativa temporanea. Infine, se non disponete di un WAF applicativo in grado di ispezionare il traffico REST API, valutate l’attivazione di una soluzione di questo tipo come priorita’ immediata.
La scala degli store coinvolti — stimati tra 112.000 e 130.000 a livello globale, per un volume di transazioni combinato di 173 miliardi di dollari annui — rende PolyShell uno degli scenari di rischio piu’ significativi per l’ecosistema Magento degli ultimi anni. La velocita’ con cui gli attacchi si sono automatizzati, passando da scanning a exploitation massiva in meno di due settimane, non lascia margine per rimandare.
Se avete dubbi sulla sicurezza della vostra installazione o volete un’analisi forense professionale, potete contattarci direttamente.
