Perché una falla patchata mesi fa continua a infettare siti WooCommerce

Il caso che spiega il problema

A febbraio 2026 lo sviluppatore Rymera Web Co ha corretto una falla critica nel plugin WooCommerce Wholesale Lead Capture: una vulnerabilità critica che permetteva il caricamento di file PHP eseguibili, con Wordfence che ha bloccato più di 100.000 tentativi di exploit a partire da giugno, nonostante una versione corretta fosse disponibile da febbraio. Il punteggio di gravità non lascia dubbi: Wordfence ha classificato CVE-2026-27540 con CVSS 9,8.

Il dettaglio che interessa chi gestisce molti siti è la cronologia. La versione 2.0.3.2, che ha corretto il bug, è stata rilasciata il 20 febbraio. Eppure Wordfence ha registrato lo sfruttamento più intenso tra il 4 e il 17 giugno, seguito da altra attività il 1° luglio e il 30 agosto. Un'altra testata ha calcolato che, al momento della scoperta dello sfruttamento attivo, la patch era disponibile da quasi sei mesi.

Il punto che il comunicato dello sviluppatore non dice, e che gli analisti sottolineano, è questo: aggiornare il plugin è solo una parte della risposta, perché una web shell piazzata prima dell'aggiornamento può restare sul server anche dopo che il percorso di upload vulnerabile è stato chiuso. Chi ha gestito un sito con quella versione del plugin tra febbraio e giugno deve quindi controllare i file, non solo la versione installata.

Perché l'aggiornamento automatico da solo non basta

L'aggiornamento automatico dei plugin WordPress copre le versioni minori, ma molte agenzie lo disattivano su plugin commerciali o lo lasciano disabilitato di default su installazioni gestite via licenza manuale. Il risultato è che nessuno controlla davvero, settimana dopo settimana, quali plugin sono rimasti indietro su quali siti. Con dieci o venti installazioni il controllo manuale dalla dashboard di ciascuna diventa un lavoro che nessuno fa con costanza.

Il controllo settimanale con WP-CLI

Su un singolo sito, il comando per vedere solo i plugin con un aggiornamento disponibile è:

wp plugin list --update=available

Per un'installazione multisito, lo stesso controllo va ripetuto su ogni sottosito usando il flag --url:

for site in $(wp site list --field=url); do
 echo "=== $site ==="
 wp plugin list --update=available --url=$site
done

Se invece si gestiscono installazioni separate (il caso tipico di un'agenzia con più clienti su percorsi diversi dello stesso server o su server diversi), lo stesso controllo si fa puntando al percorso di ciascuna installazione con --path:

SITI=(
 "/var/www/cliente1"
 "/var/www/cliente2"
 "/var/www/cliente3"
)

for s in "${SITI[@]}"; do
 echo "=== $s ==="
 wp plugin list --update=available --path="$s"
done

Messo in un file ed eseguito via cron una volta a settimana con output reindirizzato a un log o inviato per email, questo script dà in pochi secondi l'elenco di tutti i plugin desaggiornati su tutti i siti gestiti, compreso il nome esatto del plugin e la versione installata rispetto a quella disponibile. È lo stesso output che si otterrebbe aprendo una per una le dashboard, ma in un unico comando.

Cosa fare con l'elenco

Un elenco settimanale non sostituisce il controllo di sicurezza, ma lo rende possibile: permette di sapere, prima che lo scopra un avviso esterno, quali siti hanno un plugin vulnerabile ancora installato. Per i plugin segnalati con CVE attivo, il controllo in più da fare non è solo "ho aggiornato", ma "il sito ha ricevuto richieste sospette prima dell'aggiornamento", verificabile nei log di accesso del periodo in cui la versione vulnerabile era attiva.