WordPress si autorigenera, Kiteworks espone il gateway email a RCE

🛡️ Executive Summary

• Una campagna WordPress documentata da Monarx utilizza nove meccanismi di persistenza capaci di ricostruire il malware dopo una bonifica incompleta.
• Il malware nasconde amministratori, usa un Service Worker nel browser, comunica tramite smart contract Ethereum e può propagarsi tra siti sullo stesso hosting.
• Kiteworks ha corretto CVE-2026-54154, vulnerabilità critica dell’Email Protection Gateway che può portare da accesso remoto non autenticato a esecuzione di codice e controllo root.

Due problemi apparentemente lontani mostrano lo stesso limite delle difese applicative: eliminare il file malevolo o installare una patch non basta quando l’attaccante riesce a controllare i livelli che ricostruiscono lo stato del sistema. Una campagna contro WordPress ha costruito una persistenza distribuita tra filesystem, database, WP-Cron, tema, browser e installazioni vicine, mentre Kiteworks ha corretto una vulnerabilità massima nel proprio Email Protection Gateway capace di trasformare input non autenticato in esecuzione di codice. Il punto comune non è il prodotto colpito, ma la capacità di passare dal singolo bug al controllo dell’infrastruttura che gestisce il contenuto.

WordPress ricostruisce il malware anche dopo la cancellazione dei file

La ricerca originaria di Monarx sulla campagna WordPress descrive un impianto progettato per sopravvivere alle normali procedure di cleanup. Il malware cerca innanzitutto di installarsi come must-use plugin, invisibile al normale ciclo di attivazione dei plugin, e mantiene copie della propria configurazione nel database. Monarx ha individuato nove meccanismi indipendenti di persistenza, ciascuno in grado di ripristinare il payload principale se quello presente sul filesystem viene eliminato o ridotto.

Entrano in gioco db.php, advanced-cache.php, object-cache.php, il functions.php del tema, .htaccess, .user.ini, WP-Cron e copie memorizzate dentro wp_options. La capacità di nascondersi all’interno del normale funzionamento WordPress ricorda perché le vulnerabilità nei plugin WordPress continuano a essere un vettore privilegiato per compromettere siti esposti: in questo caso però il problema prosegue anche dopo il primo accesso.

Leggi anche: APT36 usa ClickFix per infettare gli utenti attraverso interazioni apparentemente legittime

C2 su Ethereum e Service Worker spostano la persistenza fuori dal server

L’elemento più insolito è l’uso della blockchain per risolvere l’infrastruttura di comando e controllo. Il malware esegue chiamate eth_call verso smart contract Ethereum hardcoded, ottenendo chiavi XOR e indirizzi C2 senza affidarsi a un dominio centrale facilmente sospendibile. Circa ogni dieci ore il componente invia informazioni sul sito compromesso, plugin installati, URL di login e account amministrativi e può ricevere nuove versioni del malware o configurazioni per ulteriori meccanismi di persistenza. Ancora più critico è il Service Worker malevolo registrato nel browser degli amministratori WordPress: intercetta le richieste verso wp-login.php, può acquisire credenziali e, sfruttando la sessione già autenticata, automatizzare nuovamente il caricamento del plugin compromesso. Una bonifica interamente server-side può quindi fallire perché il browser di un amministratore continua a conservare il punto di rientro. Lo stesso principio alla base di ClickFix — trasformare un’interazione apparentemente legittima in esecuzione controllata dall’attaccante — mostra quanto la distinzione tra compromissione web e compromissione endpoint sia diventata sempre meno netta.

Kiteworks CVE-2026-54154 porta il gateway email fino al controllo root

Sul fronte enterprise, Kiteworks ha corretto CVE-2026-54154, una vulnerabilità classificata con severità massima nell’Email Protection Gateway. L’advisory e la dichiarazione tecnica di Kiteworks: la falla nasce dalla combinazione di problemi nella gestione dell’input su endpoint pubblicamente raggiungibili e può consentire a un aggressore remoto non autenticato di ottenere esecuzione arbitraria di codice. La catena combina path traversal, code injection e assenza di autenticazione; ulteriori debolezze locali possono poi portare alla compromissione amministrativa completa dell’appliance. Sono coinvolte le versioni di Email Protection Gateway precedenti alla 9.4.1, mentre la release 9.4.1 contiene il fix. L’impatto è particolarmente rilevante perché il gateway opera precisamente nel punto nel quale email e contenuti provenienti dall’esterno vengono processati prima di raggiungere gli utenti e gli altri servizi dell’organizzazione.

La correzione arriva all’interno di un intervento molto più ampio: Kiteworks ha risolto complessivamente 126 vulnerabilità, comprese altre falle critiche relative a bypass dell’autenticazione, acquisizione di account amministrativi, stored XSS e controlli di accesso nei componenti Core ed EPG. La gravità della vulnerabilità principale non dipende quindi soltanto dalla possibilità teorica di eseguire codice, ma dalla collocazione dell’appliance nella rete: un sistema che gestisce flussi email e contenuti aziendali diventa un possibile punto di transito verso infrastrutture interne. La stessa classe di rischio ricorre ogni volta che una vulnerabilità applicativa consente di oltrepassare il confine tra dati ricevuti e codice eseguito.

Continua con:
Vulnerabilità critiche in plugin WordPress, SonicWall, KerioControl e Ivanti
Magnet Goblin sfrutta vulnerabilità di servizi esposti per distribuire malware

Persistenza e appliance esposte cambiano il concetto di bonifica

Le due vicende descrivono due estremi dello stesso problema operativo. Nel caso WordPress, la persistenza è distribuita: cancellare un file non serve se database, cron, browser o un’altra installazione riescono a ricrearlo. Monarx indica infatti una sequenza di bonifica precisa che parte dal contenimento, passa dalla rimozione dei loader sempre attivi e delle copie nel database e arriva fino alla cancellazione del Service Worker dai browser degli amministratori. Nel caso Kiteworks la priorità è differente ma altrettanto netta: i sistemi EPG precedenti alla 9.4.1 devono essere aggiornati, perché il difetto interessa endpoint raggiungibili da remoto e può arrivare all’esecuzione di codice senza credenziali. In entrambi i casi, però, il punto tecnico è identico: la sicurezza non coincide con la rimozione dell’artefatto visibile. Bisogna eliminare o correggere anche tutti i meccanismi che possono ricostruire accesso, privilegi o stato compromesso. È questa la differenza tra cancellare un malware e riprendere realmente il controllo dell’infrastruttura.