WordPress e VMware sotto attacco: webshell su WooCommerce e ransomware contro vCenter

🛡️ Executive Summary

• CVE-2026-27540 permette il caricamento di file PHP senza autenticazione su WooCommerce Wholesale Lead Capture fino alla versione 2.0.3.1.
• Wordfence ha bloccato oltre 100.000 tentativi di exploit: gli attaccanti caricano webshell e possono arrivare al controllo completo del sito WordPress.
• CISA segnala ora CVE-2026-59310 di VMware vCenter anche nelle campagne ransomware, dopo le compromissioni con reverse SSH osservate ad agosto.

Due vulnerabilità già corrette mostrano quanto rapidamente una falla esposta possa trasformarsi in accesso persistente e compromissione completa. Su WordPress, gli attaccanti stanno sfruttando CVE-2026-27540 nel plugin premium WooCommerce Wholesale Lead Capture per caricare webshell PHP senza alcuna autenticazione. Wordfence dichiara di aver bloccato oltre 100.000 tentativi di exploit. Sul fronte enterprise, invece, CVE-2026-59310 di VMware vCenter compie un ulteriore salto: dopo le compromissioni osservate ad agosto con reverse SSH, CISA ha aggiornato il proprio catalogo KEV indicando che la vulnerabilità viene utilizzata anche in campagne ransomware. I due casi colpiscono ambienti completamente differenti, ma condividono lo stesso problema operativo: applicare la patch dopo lo sfruttamento non elimina automaticamente webshell, persistence e accessi già creati dall’attaccante.

WooCommerce Wholesale Lead Capture permette di caricare PHP senza autenticazione

La prima campagna prende di mira WooCommerce Wholesale Lead Capture, plugin premium utilizzato per aggiungere moduli di registrazione dedicati ai clienti wholesale. La ricerca pubblicata da Wordfence identifica la falla come CVE-2026-27540, valutata CVSS 9,8, e conferma che tutte le versioni fino alla 2.0.3.1 sono vulnerabili. La correzione è disponibile dalla 2.0.3.2, rilasciata già il 20 febbraio 2026. Il problema risiede nell’action AJAX wwlc_file_upload_handler, raggiungibile anche da utenti non autenticati.

Il plugin verifica l’estensione del file rispetto a una lista di tipi consentiti, ma quella lista viene letta direttamente dal parametro file_settings fornito nella richiesta. Un attaccante può quindi inserire php tra i formati ammessi e convincere il server ad accettare un file eseguibile. È lo stesso schema già osservato nella campagna globale contro CMS che utilizzava upload arbitrari per installare webshell persistenti: il bug apparentemente limitato alla gestione di un file diventa un percorso diretto verso l’esecuzione di codice sul server.

Oltre 100.000 tentativi mostrano che la vulnerabilità è ormai industrializzata

Wordfence afferma di avere bloccato oltre 100.000 richieste di exploit, con picchi tra il 4 e il 17 giugno, il 1° luglio e il 30 agosto. Gli attaccanti inviano una richiesta verso /wp-admin/admin-ajax.php, dichiarano arbitrariamente PHP come estensione consentita e caricano una webshell, spesso denominata shell.php.

Una volta scritta nella directory degli upload, la webshell può raccogliere informazioni sull’host e offrire una seconda interfaccia per caricare ulteriori file. Da quel momento la vulnerabilità del plugin smette di essere il problema principale: l’attaccante può installare backdoor aggiuntive, creare amministratori WordPress, sottrarre dati o modificare i contenuti del sito. Il comportamento ricorda molto da vicino CVE-2026-32475 di Elementor Pro, sfruttata oltre 190.000 volte per caricare direttamente webshell PHP. I due casi confermano una dinamica ormai ricorrente nell’ecosistema WordPress: le vulnerabilità di arbitrary file upload senza autenticazione vengono rapidamente trasformate in campagne automatizzate, indipendentemente dalle dimensioni del sito bersaglio.

Leggi anche: WordPress ha già superato centinaia di migliaia di tentativi di exploit contro plugin vulnerabili nelle campagne di settembre

Aggiornare il plugin non basta se la webshell è già sul server

Per chi utilizza WooCommerce Wholesale Lead Capture, la priorità è aggiornare almeno alla versione 2.0.3.2. Ma la remediation deve distinguere tra sito vulnerabile e sito già compromesso. Wordfence raccomanda di cercare file PHP inattesi o creati recentemente, in particolare nelle directory di upload, controllare nei log le richieste verso admin-ajax.php che richiamano wwlc_file_upload_handler e verificare la presenza di account amministrativi sconosciuti. Se esiste evidenza di compromissione, cancellare il singolo file malevolo non è sufficiente: un attaccante che ha ottenuto code execution può avere inserito persistenza in plugin, temi, cron job, database o altri percorsi scrivibili. Matrice Digitale aveva già documentato questa evoluzione quando malware nascosto nei MU-Plugins trasformava installazioni WordPress compromesse in accessi difficili da individuare. Nei casi confermati la risposta più sicura resta quindi ricostruire il sito da una copia attendibile, verificare l’integrità dei file e ruotare le credenziali accessibili dall’ambiente compromesso.

CVE-2026-59310 passa dalla reverse SSH alle campagne ransomware

Il secondo fronte riguarda VMware vCenter ed è ancora più sensibile perché colpisce il sistema che governa l’infrastruttura virtuale enterprise. Broadcom ha corretto CVE-2026-59310 il 29 luglio all’interno dell’advisory VMSA-2026-0006. La vulnerabilità è una directory traversal critica nel vCenter Syslog Server, valutata CVSS 9,8, che permette a un attaccante non autenticato con accesso di rete al servizio di arrivare all’esecuzione arbitraria di codice. Non esiste un workaround equivalente alla patch. Il rischio era emerso quasi immediatamente dopo la disclosure: Matrice Digitale aveva ricostruito ad agosto lo sfruttamento di CVE-2026-59310 con installazione di reverse SSH e compromissioni osservate in 47 Paesi. La novità di settembre è che CISA ha aggiornato la voce del catalogo Known Exploited Vulnerabilities indicando anche l’impiego nelle operazioni ransomware, trasformando una RCE già sfruttata in un vettore associato direttamente all’estorsione.

vCenter vale più di un normale server perché controlla l’intera virtualizzazione

La pericolosità di CVE-2026-59310 deriva dalla posizione occupata da vCenter nell’architettura aziendale. Compromettere un normale server applicativo può offrire un punto d’ingresso nella rete; prendere il controllo dell’infrastruttura di management VMware può invece aprire la strada verso host ESXi, macchine virtuali, datastore, credenziali amministrative e sistemi interni. È per questo che i gruppi ransomware investono da anni in strumenti specificamente progettati per ambienti VMware. Il passaggio non è nuovo: varianti Linux dei ransomware dedicate a VMware ed ESXi circolano da anni proprio per cifrare direttamente le macchine virtuali, mentre altri attori hanno sfruttato vulnerabilità ESXi per uscire dalle VM o raggiungere dati presenti sugli host. Nel caso di CVE-2026-59310, la combinazione tra assenza di autenticazione e code execution rende particolarmente pericolose le installazioni raggiungibili da reti non fidate.

Broadcom aveva classificato la patch come emergency change

La gravità era evidente già a luglio. Broadcom aveva raccomandato alle organizzazioni di trattare le correzioni come emergency change, installandole senza attendere il normale ciclo di manutenzione. Per vCenter le versioni corrette comprendono 9.1.0.0300, 9.0.2.0100 e 8.0 Update 3k, mentre i prodotti Cloud Foundation e le piattaforme telco seguono percorsi di aggiornamento specifici. Nello stesso advisory vengono corrette anche CVE-2026-59309, authentication bypass pre-authentication, e CVE-2026-47876, vulnerabilità VMXNET3 capace di consentire una VM escape verso l’host ESX. L’insieme rende l’aggiornamento particolarmente delicato: non si tratta di correggere un singolo componente periferico, ma diversi confini di fiducia dell’ambiente VMware. La piattaforma aveva già mostrato questo tipo di esposizione nelle vulnerabilità Workstation e Fusion capaci di attraversare il confine tra macchina virtuale e host.

Una patch tardiva chiude la porta ma non caccia chi è già entrato

WordPress e VMware convergono soprattutto su questo punto operativo. La patch interrompe il vettore iniziale, ma non costituisce una bonifica. Nel plugin WooCommerce, una webshell può restare accessibile dopo l’aggiornamento. In vCenter, gli attaccanti osservati ad agosto installavano reverse_ssh e cron job per mantenere l’accesso anche dopo la compromissione iniziale. Un’organizzazione che aggiorna CVE-2026-59310 settimane dopo l’esposizione deve quindi cercare attività anomala antecedente alla patch, processi inattesi, modifiche ai cron, connessioni outbound e nuovi meccanismi di persistence. È la stessa distinzione emersa recentemente in altri prodotti enterprise: PaperCut, GiveWP e altre RCE hanno mostrato come la fase successiva all’exploit sia spesso più importante del bug originario. Dove l’exploitation è confermata, la domanda non può più essere soltanto “il sistema è aggiornato?”, ma “era vulnerabile quando gli attaccanti hanno iniziato a sfruttarlo?”.

Continua con:

• WordPress sotto pressione: cinque falle critiche aprono a takeover e RCE su plugin molto diffusi
• vCenter era già sotto attacco pochi giorni dopo la patch con persistenza tramite reverse SSH

WordPress e VMware mostrano perché l’exploitation reale cambia la priorità

CVE-2026-27540 e CVE-2026-59310 non sono nuove vulnerabilità. Sono vulnerabilità già corrette che continuano a produrre compromissioni perché sistemi vulnerabili sono rimasti online abbastanza a lungo da diventare bersagli. È una distinzione fondamentale per la gestione delle patch.

Nel caso WordPress, un plugin installato su circa 6.000 siti è sufficiente a generare oltre 100.000 tentativi di exploit perché il costo dell’automazione è quasi nullo. Nel caso VMware, bastano poche centinaia di vCenter esposti per offrire ai ransomware un bersaglio ad altissimo valore, perché una singola compromissione può aprire l’intera infrastruttura virtuale.

Per gli amministratori WordPress la priorità è portare WooCommerce Wholesale Lead Capture almeno alla 2.0.3.2 e cercare indicatori di webshell o account amministrativi anomali. Per VMware è necessario verificare le release corrette indicate da Broadcom e, se il vCenter è rimasto esposto dopo luglio, affiancare alla patch una vera attività di incident hunting.

La lezione comune è semplice: quando una CVE entra nell’exploitation reale, l’aggiornamento smette di essere manutenzione e diventa risposta a un possibile incidente già avvenuto.