La finestra tra la divulgazione pubblica di una vulnerabilità critica e il suo sfruttamento attivo si sta riducendo in modo preoccupante. Nel caso di PolyShell, la vulnerabilità che colpisce Magento Open Source versione 2 e Adobe Commerce, sono bastati appena due giorni dalla pubblicazione dei dettagli tecnici perché iniziassero campagne di attacco su scala massiva. Secondo i dati raccolti da Sansec, azienda specializzata nella sicurezza delle piattaforme eCommerce, oltre il 56% degli store esposti a questa vulnerabilità risulta già nel mirino degli attaccanti.

Il meccanismo alla base di PolyShell è tanto elegante quanto pericoloso. Il problema risiede nelle API REST di Magento, che accettano upload di file come parte delle opzioni personalizzate per gli articoli nel carrello. Questo comportamento, di per sé legittimo dal punto di vista funzionale, diventa un vettore di attacco quando si sfruttano i cosiddetti file poliglotti (file che rispettano simultaneamente la struttura di due o più formati distinti). A seconda della configurazione del server web, questi file possono innescare un’esecuzione di codice remota (RCE), oppure consentire una compromissione degli account tramite cross-site scripting persistente (XSS stored).

Adobe ha rilasciato una correzione nella versione 2.4.9-beta1 il 10 marzo 2026, ma il fix non è ancora approdato al ramo stabile del software. Le installazioni in produzione, quindi, restano prive di una patch ufficiale e al momento non è stata comunicata una tempistica precisa per il rilascio di un aggiornamento destinato agli ambienti live. Sansec ha nel frattempo pubblicato un elenco aggiornato degli indirizzi IP coinvolti nelle scansioni attive, mettendo a disposizione degli amministratori uno strumento immediato per monitorare le proprie esposizioni.

Crediti: Shutterstock

Crediti: Shutterstock

Tra le tecniche osservate nel corso di questi attacchi, spicca l’utilizzo di uno skimmer per carte di pagamento che sfrutta WebRTC come canale di esfiltrazione dei dati. WebRTC opera tramite UDP cifrato con DTLS, un protocollo completamente diverso dall’HTTP tradizionale. Questo significa che le regole di Content Security Policy (CSP) comunemente adottate, come la direttiva connect-src, non sono in grado di intercettare o bloccare questo tipo di traffico, rendendo lo skimmer sostanzialmente invisibile alle difese perimetrali più diffuse.

Il codice malevolo si presenta come un loader JavaScript compatto che stabilisce una connessione con un server di comando e controllo (C2) attraverso WebRTC, simulando uno scambio SDP contraffatto per aggirare i normali meccanismi di segnalazione. Una volta instaurato il canale cifrato, il loader riceve ed esegue un payload di secondo stadio, adottando diverse strategie per eludere la CSP, riutilizzare un nonce di script già presente nella pagina, ricorrere a unsafe-eval, oppure iniettare direttamente tag script nel DOM.

Per ridurre ulteriormente la probabilità di essere rilevato, l’esecuzione del codice viene ritardata tramite requestIdleCallback, un’API del browser pensata per differire operazioni non urgenti ai momenti di inattività del thread principale, un dettaglio che rivela una cura non banale nell’ingegnerizzazione dell’attacco.

La portata reale del problema emerge con chiarezza da un caso concreto riportato da Sansec, nel quale lo skimmer è stato individuato sul sito eCommerce di un costruttore automobilistico con una capitalizzazione superiore ai 100 miliardi di dollari. Un dato che racconta quanto anche i player più grandi possano essere impreparati di fronte a minacce che evolvono più velocemente dei cicli di patching.

(Immagine in apertura: Shutterstock)