Una campagna XSS contro WordPress inserisce quattro vie di accesso nei siti
Una campagna XSS contro WordPress sta sfruttando falle in due plugin non correlati per eseguire JavaScript dannoso quando un amministratore visualizza dati dei clienti memorizzati. Patchstack ha osservato per la prima volta l'attività il 4 ottobre 2026, diretta contro CVE-2026-93836 in WPC Product Bundles for WooCommerce, seguita il 5 ottobre da CVE-2026-94504 in Ninja Forms. Entrambi gli attacchi caricano lo stesso script da imgcdn1.com, che utilizza quindi la sessione attiva dell'amministratore per installare malware e stabilire quattro vie di accesso separate al sito web. Patchstack afferma che lo sfruttamento è attivo, ma rimane limitato nella sua telemetria, e che le due falle di distribuzione confermate non devono essere considerate il totale definitivo.
Entrambe le vulnerabilità sono falle di stored cross-site scripting, o stored XSS, non autenticate. Ciò significa che un attaccante può salvare codice dannoso per il browser in un sito senza effettuare il login e poi attendere che il codice venga eseguito quando un amministratore apre il record interessato. CVE-2026-93836 interessa WPC Product Bundles for WooCommerce fino alla versione 8.6.6 e ha un punteggio di gravità CVSS pari a 7.1. Gli attaccanti hanno fornito, tramite il parametro woosb_ids[…][qty], una quantità che iniziava con un numero valido seguito da un elemento script. Il valore ha superato la validazione, è rimasto nei metadati dell'ordine WooCommerce ed è stato successivamente visualizzato senza una protezione adeguata. Il plugin conta più di 30.000 installazioni attive e il suo changelog indica la versione 8.6.7 come correzione di sicurezza.
CVE-2026-94504, anch'essa classificata CVSS 7.1, interessa Ninja Forms fino alla versione 3.15.3, un plugin con più di 500.000 installazioni attive. Il suo normale endpoint di invio AJAX accettava contenuti controllati dall'attaccante nei campi textarea non rich-text. Il vecchio editor amministrativo degli invii poteva quindi visualizzare tali contenuti senza codificarli in modo sicuro, consentendo l'esecuzione di JavaScript quando l'invio veniva visualizzato. La versione 3.15.4 ha rafforzato l'output escaping in quella schermata. Sebbene i loader iniettati fossero adattati ai diversi contesti dei moduli e degli ordini, entrambi recuperavano il payload centralizzato da https://imgcdn1.com/fz/x.js.
L'analisi di Patchstack ha rilevato che x.js è uno script di post-exploitation di 19.378 byte, ossia codice utilizzato dopo che l'accesso iniziale è già stato ottenuto. Non ruba il cookie dell'amministratore e non richiede un'altra falla del server. Poiché viene eseguito nel contesto del browser del sito compromesso, le richieste a wp-admin includono automaticamente la sessione autenticata dell'amministratore. Lo script apre pagine privilegiate, estrae CSRF nonces, valori temporanei utilizzati da WordPress per confermare le azioni amministrative, e invia tali valori tramite funzioni legittime di WordPress. La protezione dei cookie HttpOnly non lo blocca, perché il codice non ha mai bisogno di leggere direttamente il cookie.
Prima di apportare modifiche, x.js contatta il server command-and-control, o C2, all'indirizzo imgcdn1.com/fz/c.php, inviando l'indirizzo del sito bersaglio. La risposta indica se le fasi relative al plugin, all'amministratore e alla persistenza aggiuntiva sono riuscite. Lo script registra inoltre l'avanzamento nella Local Storage del browser sotto una key che inizia con __xp_v9_, contrassegnando le fasi come plugin, admin, emer e infine all. Comunica i risultati tramite fetch(), sendBeacon() o una richiesta di immagine, offrendo al messaggio di stato diversi modi per sopravvivere alla navigazione tra le pagine.
Utilizzando la sessione dell'amministratore, il malware apre la pagina di caricamento dei plugin di WordPress, ne raccoglie il nonce e scarica un pacchetto ZIP dal C2. Il pacchetto viene installato come wp-smart-thumbnails e si spaccia per “WP Smart Thumbnails” 1.2.4 di “MediaPress Labs”. I suoi quattro file includono il dropper wp-smart-thumbnails.php da 20.728 byte, l'installer di persistenza emer-run.php da 14.330 byte e due piccoli file esca. Tutti riportano timestamp di luglio 2026, precedenti alla campagna. Il file principale termina l'esecuzione quando WordPress lo carica normalmente e funziona soltanto tramite una richiesta web diretta, contribuendo a farlo apparire inattivo nella dashboard.
Il dropper nasconde il proprio payload dietro sette trasformazioni che coinvolgono Base64, XOR, inversione, ROT13, rotazione dei byte e decompressione, seguite da un controllo di integrità MD5. Anziché utilizzare la funzione eval(), comunemente rilevata, registra lo stream wrapper dyiv:// e include il codice decodificato tramite tale indirizzo. Il risultato è un file manager grafico di circa 37 KB intitolato “Moon, tell me if I could”. Non richiede password, token o permessi WordPress e può elencare, caricare, eliminare, rinominare, creare, leggere e salvare file tramite un'interfaccia JSON. Non richiama direttamente system() o exec(), ma la sua capacità di scrivere file controllati dall'attaccante in qualsiasi posizione scrivibile è sufficiente per installare un'altra webshell, uno strumento accessibile via web per controllare file o eseguire ulteriore codice dannoso.
Il componente emer-run.php crea l'accesso più durevole. Per prima cosa aggiunge un account con privilegi completi, dotato di uno username dall'aspetto ordinario selezionato tra parole come support, updater, maintenance o backup, un indirizzo email @wordpress.org e una password casuale di 16 caratteri. Scrive quindi un must-use plugin, un'estensione WordPress che si carica automaticamente e non può essere disabilitata dalla normale schermata dei plugin. Gli hook presenti in quel file rimuovono l'account dalle query degli utenti, dai filtri degli amministratori e dai totali visualizzati, così che non compaia nella sezione Utenti e non venga conteggiato. La rimozione del plugin wp-smart-thumbnails non elimina questo amministratore nascosto.
Un secondo must-use plugin crea /wp-login.php?_wplogin=. Chiunque disponga di un token valido viene autenticato silenziosamente come l'amministratore esistente più vecchio del sito, in genere il proprietario originale, anziché come l'account nascosto. I log che registrano soltanto l'ID utente possono quindi far apparire autentica la sessione. Entrambi i must-use plugin sono offuscati con una key diversa e nomi di variabili casuali su ogni sito infetto, impedendo a un singolo file hash di identificare tutte le copie. L'installer individua inoltre la data di modifica più vecchia nella root di WordPress e la applica ai nuovi file, rendendo inefficaci le ricerche basate soltanto sulle modifiche recenti.
Una singola esecuzione riuscita lascia quindi quattro metodi di accesso indipendenti: un amministratore visibile creato con credenziali provenienti dal C2, l'amministratore nascosto, l'URL di login speciale per l'amministratore più vecchio e il file manager non autenticato. Soltanto il primo è normalmente visibile in WordPress. La stored XSS è particolarmente efficace in questo caso perché l'attaccante non deve convincere un amministratore ad aprire un link speciale. Il payload rimane in attesa all'interno di un normale ordine o invio di modulo. WordPress 7.1.1 ha corretto nel settembre 2026 un problema separato di stored XSS non autenticata in wpautop(), dimostrando che questo modello di attacco non è limitato a un singolo plugin.
Il domain imgcdn1.com ospitava l'impianto per browser, i controlli sulle vittime, il pacchetto del plugin dannoso, le credenziali selezionate dall'attaccante e i report sulle compromissioni. È stato registrato il 1° ottobre, delegato a un nameserver Cloudflare il 2 ottobre ed è apparso per la prima volta nella telemetria di Patchstack alle 10:39 UTC del 4 ottobre. Le due falle dei plugin erano state divulgate pubblicamente il 22 settembre.