Magento, 953 negozi infettati con JavaScript invisibile agli scanner

🛡️ Executive Summary

• Sansec identifica una campagna attiva dal luglio 2025 che ha compromesso 953 negozi online, prevalentemente Magento, attraverso loader JavaScript nascosti nei blocchi CMS.
• Il nuovo dominio deepveindrilling.com interessa 83 negozi e utilizza il fingerprinting del browser per riconoscere gli scanner e nascondere il codice malevolo.
• PolyShell e SessionReaper hanno favorito le compromissioni iniziali, ma la campagna interessa anche installazioni aggiornate attraverso account amministrativi abusivi e backdoor persistenti.

Magento torna al centro di una campagna di compromissione che ha raggiunto 953 negozi online, prevalentemente basati sulla piattaforma Adobe Commerce e Magento Open Source, attraverso un sistema di distribuzione JavaScript progettato per distinguere i clienti reali dagli strumenti di sicurezza. La ricerca pubblicata da Sansec il 24 ottobre 2026 ricostruisce un’operazione avviata nel luglio 2025 e ancora attiva, nella quale gli aggressori nascondono loader malevoli all’interno dei blocchi CMS, cambiano periodicamente infrastruttura e utilizzano il fingerprinting per eludere i controlli automatici. Il dato più rilevante non riguarda soltanto il numero dei negozi compromessi: gli attaccanti riescono a mantenere accessi persistenti e a modificare il codice eseguito dai browser anche dopo l’applicazione degli aggiornamenti di sicurezza.

Sansec ricostruisce una campagna durata 15 mesi con cinque domini principali

La ricerca originale del Sansec Forensics Team identifica 953 negozi colpiti complessivamente dal luglio 2025, senza indicare che tutte le compromissioni siano contemporaneamente attive. La campagna ha utilizzato cinque infrastrutture principali: manulfie[.]click, comparso nel luglio 2025 e osservato su 863 negozi; neswnsssn[.]click, attivo da dicembre su 494; lanhd6549tdhse[.]top, individuato nel marzo 2026 su 355; additionalver[.]com, comparso a giugno su 246; e deepveindrilling[.]com, registrato il 6 ottobre e rilevato su 83 negozi. I valori non devono essere sommati perché le installazioni possono essere state raggiunte da più versioni del medesimo loader.

La continuità offensiva emerge soprattutto dall’ultima infrastruttura: 60 degli 83 negozi associati a deepveindrilling.com avevano già ospitato una precedente versione del codice, mentre 34 risultavano coinvolti fin dall’ottobre 2025. Il 7 ottobre sono comparse le prime richieste verso il nuovo dominio e, entro il giorno successivo, Sansec aveva già identificato 74 installazioni. Il passaggio di ottobre non costituisce quindi una nuova campagna indipendente, ma l’evoluzione di un’operazione che aveva già sfruttato PolyShell per compromettere massicciamente i negozi Magento, conservando la possibilità di modificare le pagine e raggiungere nuovamente i visitatori.

Leggi anche: StyleSmuggler buca Magento: zero-day RCE installa backdoor nei negozi online

Il JavaScript nei blocchi CMS riconosce scanner, bot e clienti reali

Il funzionamento tecnico del malware sfrutta una caratteristica legittima di Magento: i blocchi CMS permettono di inserire contenuti riutilizzabili nelle pagine del negozio, inclusi elementi destinati a intestazioni, sezioni promozionali e altre parti dell’interfaccia. Sansec ha individuato il loader nella tabella cms_block, rilevandolo in 148 installazioni server durante il monitoraggio della campagna, mentre non ha osservato lo stesso codice nelle tabelle core_config_data o nei file dei temi. Quando il visitatore apre una pagina compromessa, il JavaScript contatta l’infrastruttura degli aggressori, che decide quale risposta restituire. La prima variante di ottobre recuperava il payload remoto e lo conservava nel localStorage del browser attraverso la chiave fpCode, permettendo di eseguirlo nuovamente nelle visite successive anche quando il dominio esterno non era più raggiungibile. Il 23 ottobre gli attaccanti hanno modificato ulteriormente il loader, introducendo controlli su navigator.webdriver, Selenium, proprietà di ChromeDriver, GPU WebGL, memoria, processore, risoluzione e lingua del dispositivo. Questi segnali permettono di distinguere un browser automatizzato da un potenziale acquirente e ridurre la visibilità del codice durante le scansioni. La precedente infrastruttura utilizzava anche Keitaro come sistema di distribuzione selettiva del traffico, mentre l’ultima versione incorpora direttamente i controlli. Sansec non ha ancora acquisito il payload finale, quindi l’eventuale sottrazione di dati di pagamento rimane un rischio concreto ma non un evento dimostrato per questa specifica campagna. Il precedente delle operazioni Magecart contro i sistemi di pagamento mostra tuttavia perché l’esecuzione di codice remoto nel browser del cliente rappresenti una superficie particolarmente delicata.

PolyShell e SessionReaper hanno favorito le infezioni iniziali

L’indagine collega una parte consistente degli accessi alla vulnerabilità PolyShell, CVE-2026-48356, che permette di abusare delle funzionalità di caricamento dei file di Magento e Adobe Commerce. Nel marzo 2026 gli aggressori hanno distribuito il loader su 471 negozi nell’arco di un’ora, dopo aver caricato web shell attraverso il percorso vulnerabile. Sansec ha inoltre individuato 169 installazioni Magento 2 compromesse che non avevano applicato almeno una patch del core: in 102 di queste, pari a circa il 60%, erano presenti file caricati sfruttando PolyShell oppure SessionReaper, CVE-2025-54236. Questi 102 casi costituiscono un sottoinsieme osservato durante l’analisi, non un numero da aggiungere automaticamente alle 471 compromissioni della precedente ondata. Un esempio riguarda Magento 2.4.7-p1, dove gli aggressori avevano collocato web shell camuffate da immagini PNG nella directory pub/media/custom_options/quote/, accanto a un blocco CMS che richiamava additionalver.com e successivamente deepveindrilling.com. L’installazione non aveva ricevuto la correzione PolyShell prevista dal bollettino Adobe APSB26-73. Il caso conferma come il caricamento non autorizzato di file possa trasformarsi in un punto d’appoggio permanente per modificare le pagine dell’e-commerce, una dinamica che si inserisce nella più ampia sequenza di vulnerabilità critiche emerse anche con BlockStrap su Magento.

Anche un negozio aggiornato può restare compromesso attraverso gli account amministrativi

L’aspetto più significativo dell’indagine riguarda un negozio con Magento 2.4.7-p10 e nessuna patch del core mancante, sul quale Sansec ha rilevato il loader deepveindrilling.com il 23 ottobre alle 16:46 UTC, appena un’ora dopo una scansione risultata pulita. La ricostruzione forense aveva però già identificato un account amministrativo abusivo il 16 settembre e una backdoor GSocket il 24 settembre. La presenza del loader in un’installazione aggiornata non dimostra quindi necessariamente l’esistenza di una nuova zero-day: in questo caso, gli aggressori disponevano già di elementi di persistenza capaci di consentire ulteriori modifiche al sito. È proprio questo il limite di una strategia difensiva concentrata esclusivamente sul patch management. Aggiornare il software impedisce lo sfruttamento della vulnerabilità corretta, ma non elimina automaticamente gli account creati dall’attaccante, le web shell e gli accessi clandestini precedentemente installati. Sansec avverte che i negozi associati agli indicatori della campagna devono essere considerati esposti a modifiche non autorizzate del database e che rimuovere il solo JavaScript non risolve la compromissione. Il problema si estende anche alla valutazione degli strumenti di monitoraggio: un controllo automatico che riceve una risposta innocua può classificare erroneamente come pulita una pagina che distribuisce codice differente ai clienti reali. È una debolezza già osservabile nelle campagne che sfruttano Google Tag Manager per introdurre skimmer nei siti Magento, dove l’origine apparentemente legittima delle risorse rende più complessa l’individuazione del codice inserito dagli aggressori.

Continua con:

Sansec scopre una backdoor all’interno di Magento: commercianti a rischio

Europol contro lo skimming digitale: 443 e-commerce compromessi

Quali verifiche devono effettuare gli amministratori degli e-commerce italiani?

Per gli operatori italiani che utilizzano Magento e Adobe Commerce, la ricerca non documenta un numero specifico di negozi nazionali compromessi, ma identifica tecniche e indicatori direttamente applicabili alla verifica delle installazioni. Sansec raccomanda di esaminare i contenuti delle tabelle cms_block e cms_page, cercando riferimenti ai domini della campagna, sequenze codificate in Base64 e stringhe come fpCode, se_referrer e localStorage.getItem. La ricerca deve comprendere anche gli account nella tabella admin_user, i file inattesi nelle directory di caricamento, le web shell e i processi sconosciuti. Dopo la bonifica occorre correggere il vettore iniziale, rimuovere eventuali backdoor e sostituire le credenziali amministrative, del database e delle integrazioni API. Gli aggiornamenti APSB26-73 per PolyShell e APSB25-88 per SessionReaper costituiscono riferimenti necessari per la remediation delle installazioni interessate, ma la verifica deve estendersi alle patch successive e allo stato effettivo del sistema. Sul fronte dei browser, il codice conservato nel localStorage può continuare a essere eseguito finché una pagina compromessa ne richiama il contenuto; rimuovere il loader dalla pagina interrompe quel percorso di esecuzione, ma non sostituisce l’indagine sull’eventuale compromissione del server. La campagna dimostra soprattutto un limite strutturale dei controlli basati esclusivamente sulla scansione esterna: un sito può apparire sicuro agli strumenti automatizzati e distribuire contemporaneamente codice malevolo agli acquirenti, mentre la persistenza sul server consente agli aggressori di ricostruire l’infezione anche dopo una pulizia superficiale. Per questo la sicurezza del commercio elettronico richiede verifiche continue sull’integrità del database, sugli account privilegiati e sul codice realmente eseguito dai clienti, non soltanto il controllo della versione installata.