Allerta Magento: il 56% dei negozi colpiti da PolyShell. Lo skimmer “invisibile” che svuota le carte di credito

Le difese tradizionali non bastano più quando l’attacco viaggia dove nessuno guarda. La campagna PolyShell, esplosa in tutta la sua violenza il 19 marzo 2026, sta letteralmente decimando i negozi Magento e Adobe Commerce. Sfruttando una falla nella REST API per il caricamento dei file, gli attaccanti riescono a iniettare file “poliglotti” — metà immagini, metà script — ottenendo il controllo totale del server senza nemmeno bisogno di una password. Ma il vero colpo di genio criminale arriva dopo: l’installazione di uno skimmer che utilizza WebRTC per esfiltrare i dati delle carte di credito. Viaggiando su protocollo UDP cifrato, questo malware rende inutili le protezioni HTTP e le Content Security Policy (CSP), colpendo giganti del mercato valutati oltre 100 miliardi di dollari. L’e-commerce è sotto attacco: ecco come PolyShell sta riscrivendo le regole del cybercrimine.

PolyShell sfrutta la REST API di Magento per caricare file polyglot

La vulnerabilità individuata da Sansec riguarda il modo in cui Magento gestisce gli upload di file tramite la REST API associata alle opzioni personalizzate del carrello. Quando un prodotto dispone di un’opzione di tipo file, il sistema accetta un oggetto file_info che contiene dati in base64, tipo MIME e nome del file. Il contenuto viene poi scritto nella directory pub/media/custom_options/quote/, creando un punto di ingresso estremamente sensibile se non protetto con regole restrittive lato web server. Gli attaccanti trasformano questa funzionalità legittima in un vettore di compromissione caricando un file polyglot, cioè un artefatto che può comportarsi contemporaneamente come immagine e come script eseguibile. In base alla configurazione del server, il risultato cambia ma resta pericoloso in ogni scenario. In alcune installazioni il file consente RCE, in altre attiva XSS persistente che porta al takeover dell’account amministratore. In entrambi i casi il controllo dell’ambiente e-commerce passa rapidamente nelle mani dell’attaccante senza richiedere credenziali iniziali.

Magento Open Source e Adobe Commerce versione 2 risultano esposti

L’impatto descritto è esteso perché la falla interessa tutte le installazioni stabili di Magento Open Source e Adobe Commerce versione 2. Sansec rileva che oltre il 56,7 percento dei negozi vulnerabili riceve scansioni e tentativi di attacco concreti, mentre gli indirizzi IP coinvolti nella campagna superano quota 50. Questo dato evidenzia non solo la gravità tecnica della vulnerabilità ma anche la sua immediata operazionalizzazione su larga scala da parte di gruppi che dispongono di tooling automatizzato. La timeline dell’exploitation mostra una velocità notevole. La campagna di massa parte il 19 marzo 2026, appena due giorni dopo la divulgazione pubblica della falla. Questo intervallo minimo tra disclosure e attacco reale conferma una dinamica ormai consolidata nel panorama offensivo: i criminali monitorano costantemente gli advisory e trasformano in poche ore le informazioni tecniche in scanner, exploit e payload pronti all’uso. Per i merchant che dipendono da provider di hosting o da processi di aggiornamento più lenti, la finestra di reazione diventa quindi estremamente ristretta.

Adobe corregge nella beta ma i negozi in produzione restano vulnerabili

Adobe pubblica una correzione nella versione 2.4.9-beta1 il 10 marzo 2026, ma la patch non raggiunge ancora il ramo stabile di produzione. Questa circostanza crea una situazione delicata: il problema è noto, esiste una mitigazione tecnica e una correzione preliminare, ma gran parte dei negozi continua a operare su release che non ricevono ancora un fix completo pronto per ambienti mission critical. In pratica il rischio resta aperto proprio nel momento in cui gli attacchi si moltiplicano. Come misura temporanea, il produttore fornisce una configurazione campione per nginx o Apache che limita l’accesso alla directory di upload. Tuttavia molti negozi si affidano a provider esterni o a configurazioni standard che non vengono modificate con sufficiente rapidità. Questo dettaglio amplifica la portata della campagna PolyShell: la vulnerabilità non è soltanto tecnica, ma anche operativa, perché si innesta su una diffusa dipendenza da ambienti gestiti e da processi di hardening non sempre tempestivi.

Lo skimmer WebRTC introduce una nuova generazione di malware per e-commerce

Dopo l’accesso iniziale, gli attaccanti distribuiscono un nuovo skimmer di carte di credito che utilizza WebRTC per caricare payload secondari ed esfiltrare dati rubati. È un’evoluzione importante rispetto agli skimmer tradizionali, che in genere si affidano a richieste HTTP, beacon immagine o caricamenti verso endpoint esterni facilmente intercettabili da strumenti di monitoraggio. In questo caso il malware costruisce una RTCPeerConnection verso l’IP 202.181.177.177 sulla porta UDP 3479. Il canale DataChannel riceve il payload in più chunk e lo esegue al termine della connessione o dopo un timeout di 10 secondi. Tutto il traffico passa su DTLS cifrato, rendendo inefficaci molti sistemi di sicurezza che osservano solo protocolli web tradizionali. Il salto qualitativo è notevole: non si tratta più soltanto di nascondere un form grabber nel checkout, ma di usare meccanismi di comunicazione moderni e meno presidiati per mantenere l’attacco invisibile alle difese più comuni.

Il bypass della Content Security Policy rende il malware più difficile da bloccare

Uno degli aspetti più sofisticati dello skimmer riguarda il modo in cui aggira la Content Security Policy. Invece di scontrarsi frontalmente con la policy, il malware cerca i nonce già presenti negli script legittimi caricati nella pagina e li riutilizza per inserire codice malevolo che appare coerente con il contesto applicativo. Se i nonce non sono disponibili, passa a tecniche alternative come Function(code)() quando la policy consente unsafe-eval, oppure all’iniezione diretta di un tag script come ultima opzione. L’esecuzione del codice avviene inoltre in background attraverso requestIdleCallback, scelta che riduce la probabilità di rilevamenti basati su tempi di caricamento anomali o variazioni evidenti nell’esperienza utente. Questo dettaglio mostra che gli autori non puntano solo alla funzionalità malevola, ma anche alla bassa osservabilità. Il malware si comporta come un componente opportunista e paziente, che sfrutta il momento meno rumoroso del ciclo di rendering per entrare in azione senza attirare attenzione.

Sansec collega lo skimmer a breach su aziende di enorme dimensione

Sansec rileva lo skimmer su un sito e-commerce appartenente a un produttore automobilistico valutato oltre 100 miliardi di dollari e conferma che lo stesso malware compare in cinque breach su aziende multi-miliardarie negli ultimi due mesi. Tra questi casi figurano anche una top-3 banca USA e una top-10 catena di supermercati globale. Il dato suggerisce che la tecnica non sia un test isolato ma un componente già maturo di operazioni offensive contro bersagli di alto profilo. Questo elemento cambia anche la percezione del rischio per i merchant medi e piccoli. Se una tecnica riesce a passare inosservata in ambienti con budget di sicurezza elevati, processi di governance strutturati e team di incident response avanzati, il suo impatto su negozi meno protetti può risultare ancora più grave. PolyShell e lo skimmer WebRTC non rappresentano quindi un problema marginale del solo ecosistema Magento, ma un segnale più ampio dell’evoluzione delle minacce nei pagamenti digitali.

La catena di attacco unisce accesso iniziale webshell e furto di carte in tempo reale

La forza della campagna PolyShell sta nella concatenazione efficace di più fasi offensive. Gli attaccanti ottengono l’accesso iniziale senza credenziali attraverso la falla di upload, caricano il file polyglot, installano un webshell o un meccanismo persistente e iniettano poi lo skimmer direttamente nelle pagine di checkout. Da quel momento i dati delle carte di credito vengono raccolti in tempo reale mentre i clienti completano i pagamenti, e inviati via UDP cifrato al comando e controllo. Questa struttura rende l’attacco pericoloso sia per la disponibilità del sistema sia per la compliance e la reputazione del merchant. Il negozio può continuare a funzionare apparentemente in modo normale mentre il malware sottrae silenziosamente informazioni finanziarie. Il danno quindi non si manifesta necessariamente con un blocco visibile del servizio, ma con un’esfiltrazione continua e invisibile che può protrarsi nel tempo fino alla scoperta dell’incidente.

La directory pub media custom options amplifica il rischio su migliaia di negozi

Sansec sottolinea che la directory pub/media/custom_options/ rimane accessibile su migliaia di installazioni, e questo errore di configurazione amplifica l’impatto dell’intera vulnerabilità. Anche quando il software applicativo presenta un difetto, la superficie reale di attacco dipende molto da come il server web espone le directory, interpreta i file caricati e applica i controlli di esecuzione. In questo caso la combinazione tra funzionalità applicativa e accessibilità del percorso di upload crea le condizioni ideali per l’abuso. Il dato del 56,7 percento di copertura tra i target vulnerabili dimostra quanto rapidamente gli attori siano stati in grado di identificare le istanze più esposte e di automatizzare l’exploitation. L’attacco non richiede un lavoro artigianale su singoli negozi, ma si presta a campagne ampie basate su scanner e controlli standardizzati. Questo spiega perché anche merchant non particolarmente visibili possano diventare vittime di compromissioni serie nel giro di poche ore dalla disclosure.

Merchant e amministratori devono applicare subito misure di contenimento

Le raccomandazioni operative sono immediate e concrete. I negozi Magento devono bloccare l’accesso alla directory pub/media/custom_options/ tramite regole nginx o Apache, misura che rappresenta la prima linea di contenimento in assenza di una patch stabile distribuita a tutti. In parallelo è necessario verificare la presenza di file polyglot, webshell, script anomali o backdoor all’interno del percorso di upload e rimuoverli rapidamente per interrompere la catena di compromissione. Sansec suggerisce anche l’uso di eComscan per rilevare lo skimmer WebRTC, i webshell e altre minacce persistenti, mentre Sansec Shield viene presentato come soluzione in grado di bloccare in tempo reale sia l’exploitation di PolyShell sia l’iniezione del malware successivo. Gli amministratori devono inoltre monitorare i log della REST API alla ricerca di richieste anomale verso gli endpoint delle custom options e applicare regole WAF in grado di intercettare upload di file polyglot o pattern compatibili con l’attacco.

PolyShell mostra quanto velocemente evolvano le minacce contro l’e-commerce

Il caso PolyShell dimostra che gli attaccanti continuano a innovare sulle superfici più redditizie del commercio elettronico. Da un lato sfruttano un RCE non autenticato che consente accesso immediato senza credenziali. Dall’altro implementano uno skimmer stealth basato su WebRTC DataChannels, cioè una tecnologia raramente monitorata con la stessa attenzione riservata al traffico HTTP. La somma di questi due elementi crea una minaccia altamente moderna, progettata per colpire sia il server sia il browser del cliente. Per i merchant Magento il messaggio è chiaro. Non basta attendere il rilascio di una patch stabile o confidare nelle difese standard del browser come la CSP. Serve una risposta multilivello che comprenda hardening del web server, controllo dei log, scansione continua dell’ambiente, verifica delle directory sensibili e monitoraggio dei comportamenti anomali nel checkout. PolyShell non è solo una vulnerabilità da correggere: è una dimostrazione pratica del fatto che la sicurezza e-commerce deve evolvere alla stessa velocità degli attaccanti.