Magento sotto attacco: PolyShell, sfruttamento di massa in pochi giorni

Mar 25, 2026 Redazione Attacchi, In evidenza, News, RSS, Vulnerabilità 0

La vulnerabilità “PolyShell” in Magento Open Source e Adobe Commerce è passata dalla disclosure alla compromissione su larga scala in tempi estremamente rapidi: secondo Sansec, azienda specializzata in sicurezza informatica, lo sfruttamento di massa è iniziato il 19 marzo 2026, appena due giorni dopo la divulgazione pubblica, e oggi le tracce di attacco risultano presenti su circa il 56,7% degli store ancora vulnerabili.

Questa velocità è coerente con un pattern ormai ricorrente nell’e-commerce: quando un bug consente una catena semplice e automatizzabile, gli attori malevoli trasformano la scansione in infezione in poche ore, soprattutto su piattaforme diffuse e con installazioni eterogenee come Magento. Sansec, inoltre, ha pubblicato una lista di indirizzi IP utilizzati per lo scanning mirato degli shop, segnale che la fase di ricognizione e selezione delle vittime è già industrializzata.

Il cuore del problema: upload “travestito” via REST API

Dal punto di vista tecnico, PolyShell riguarda il modo in cui la REST API di Magento gestisce l’upload di file associati alle “custom options” di un articolo nel carrello. In pratica, quando una product option è di tipo file, la piattaforma può finire per accettare e processare contenuti caricati dall’utente, con il rischio che un attaccante invii un file “poliglotta”: un oggetto che appare come immagine o risorsa legittima, ma che contiene anche porzioni eseguibili o utili a innescare altre condizioni pericolose. Se la configurazione del web server e del contesto applicativo lo permette, questo meccanismo può aprire la strada a remote code execution (RCE), oppure a account takeover tramite stored cross-site scripting (XSS), sfruttando contenuti persistenti che vengono poi renderizzati o interpretati in un contesto privilegiato. In altre parole, non è “solo” un bug di input validation, ma un punto d’ingresso che, combinato con scelte di configurazione e catene note, può trasformare un e-commerce in una piattaforma di esecuzione per l’attaccante.

Patch gap e gestione del rischio: cosa sappiamo sulle correzioni

La finestra operativa degli attaccanti è stata favorita anche dal consueto problema del “patch gap” tra fix e produzione. Adobe ha indicato che una correzione è stata resa disponibile in Magento/Adobe Commerce 2.4.9-beta1 il 10 marzo 2026, ma il fix non risulta ancora arrivato ovunque, lasciando molte installazioni senza un aggiornamento “production-ready” immediato. Sul fronte ufficiale, il bollettino di sicurezza Adobe (APSB26-05) conferma l’esistenza di vulnerabilità che, se sfruttate con successo, possono portare anche a esecuzione di codice, escalation di privilegi e letture arbitrarie del file system, pur dichiarando di non essere a conoscenza di exploit in-the-wild per le vulnerabilità trattate dal bulletin. In questo scenario, la pratica difensiva più realistica non è aspettare “la patch perfetta”, ma ridurre subito l’esposizione: capire se l’istanza è raggiungibile e attaccabile via API, verificare l’eventuale presenza di anomalie in percorsi e file di upload, e potenziare telemetria e controlli attorno ai flussi di checkout.

WebRTC skimmer: esfiltrazione cifrata e anti-controlli “tradizionali”

Nel quadro degli attacchi attribuiti o sospetti legati allo sfruttamento, Sansec segnala anche la consegna di un nuovo payment-card skimmer che usa WebRTC per stabilire un canale di comunicazione e trasporto dati più elusivo rispetto ai classici beacon HTTP. L’elemento tecnico qui è importante: WebRTC può usare DataChannels su UDP con DTLS, quindi l’esfiltrazione avviene in modo cifrato e fuori dal perimetro di molti controlli pensati per traffico web “standard”, con un impatto potenziale anche su siti che applicano politiche CSP restrittive. Sansec descrive un loader JavaScript leggero che si collega a un C2 hardcoded via WebRTC, evitando il signaling tipico grazie a uno scambio SDP “forgiato”; quindi, riceve un secondo stadio sul canale cifrato e lo esegue cercando di bypassare la CSP riutilizzando un nonce già valido oppure ricorrendo a fallback più aggressivi. Per ridurre il rischio di rilevamento immediato, l’esecuzione viene posticipata con meccanismi come requestIdleCallback, spostando l’attività malevola in un momento di minore attenzione e rumore applicativo.

Condividi l'articolo