Wordfence ha bloccato 1.113 attacchi in 24 ore contro una sola falla di The Events Calendar, il plugin per eventi installato su oltre 600.000 siti WordPress. Il dato è riportato da SecurityOnline il 15 settembre 2026, che classifica la vulnerabilità come sfruttata attivamente. La correzione completa esiste dal 10 settembre, versione 6.17.4.1. La regola del firewall Wordfence per gli utenti gratuiti era programmata per il 21 settembre. In mezzo ci sono undici giorni in cui la correzione c’era e la regola gratuita no, con attacchi documentati almeno dal 15 settembre.

Perché basta un commento in attesa di moderazione

Le falle sono due, CVE-2026-78006 e CVE-2026-78159, entrambe con punteggio CVSS 9.8 e nessuna richiede login. Secondo l’analisi di Wordfence citata da SecurityOnline, il plugin passa l’output della pagina evento nel parser dei blocchi di WordPress, commenti compresi. Il core non lo fa sul testo dei commenti, solo sul contenuto dei post. L’attaccante lascia un commento con un blocco widget costruito ad arte, WordPress lo reindirizza all’anteprima di moderazione e quell’anteprima esegue il blocco prima che un moderatore lo veda.

Da lì le strade sono due. La prima usa una PHP object injection per eseguire comandi sul server. La seconda richiama funzioni arbitrarie e resetta la password dell’amministratore, poi carica un plugin malevolo. La moderazione dei commenti, che molti considerano una barriera, qui è il punto d’ingresso: l’attacco richiede i commenti attivi sulle pagine evento con l’opzione “Show comments on event pages”. Chi non può aggiornare subito li disattiva, come indica SecurityOnline, ma resta una misura temporanea. Hackread ricostruisce la cronologia: Wordfence segnala a StellarWP il 21 e il 23 agosto, un primo irrobustimento esce con la 6.17.3.1 il 26 agosto, la correzione completa con la 6.17.4.1.

Il controllo su tutti i siti in un minuto

Chi gestisce più installazioni non deve aprire dieci bacheche. Con gli alias di WP-CLI definiti in ~/.wp-cli/config.yml, ognuno con la sua riga ssh:, basta un ciclo che stampa il nome del sito accanto alla versione installata:

for s in @cliente-a @cliente-b @cliente-c; do
  printf '%s: ' "$s"
  wp "$s" plugin get the-events-calendar --field=version 2>&1 | tail -n 1
done

Il nome del sito stampato prima del risultato è la parte che conta. Senza, un sito irraggiungibile e un sito senza il plugin producono lo stesso silenzio, e il silenzio si legge come via libera. Così ogni riga dice una cosa sola: un numero di versione, oppure l’errore di wp plugin get che dichiara il plugin assente, oppure l’errore della connessione SSH. Tutto quello che mostra una versione inferiore a 6.17.4.1 va aggiornato adesso. Sugli alias vale la stessa guardia che ho descritto per gli script WP-CLI lanciati sul sito sbagliato: controlla che ogni alias punti dove credi prima di aggiornare in serie.

Aggiornare, attivare l’automatico, cercare tracce

Per ogni sito rimasto indietro servono tre comandi. Il primo aggiorna, il secondo attiva l’aggiornamento automatico solo per questo plugin, il terzo verifica il risultato leggendo i campi version e auto_update di wp plugin list:

wp @cliente-a plugin update the-events-calendar
wp @cliente-a plugin auto-updates enable the-events-calendar
wp @cliente-a plugin list --name=the-events-calendar --fields=name,version,auto_update

Al 28 settembre la pagina ufficiale del plugin indica la 6.17.5.1, rilasciata il 24 settembre: l’aggiornamento porta lì, oltre la soglia. Se il sito è rimasto scoperto durante la finestra di attacco, aggiornare chiude la porta ma non caccia chi è già entrato. La seconda catena non crea un account nuovo: cambia la password dell’amministratore esistente e poi carica un plugin. Quindi si cerca il plugin. wp plugin list --fields=name,status,version mostra tutto quello che è installato, e un nome che non riconosci è il primo segnale. wp plugin verify-checksums --all confronta i file con quelli pubblicati su WordPress.org, e un plugin che lì non esiste risulta non verificabile. Non trova tutto, perché una backdoor in wp-content/uploads gli sfugge, ma in due comandi fa emergere i segnali più evidenti.

L’errore da evitare: aspettare il firewall gratuito

Secondo Hackread, i clienti Premium, Care e Response di Wordfence sono protetti dal firewall dal 22 agosto, mentre per il firewall gratuito la regola era programmata per il 21 settembre: trenta giorni dopo. Non è un difetto: è la differenza fra il piano gratuito e quelli a pagamento. Il problema nasce quando un sito tratta il WAF free come la sua difesa principale e rimanda gli aggiornamenti perché tanto c’è il plugin di sicurezza. In questo caso la patch è arrivata prima della regola gratuita, e chi aggiornava non aveva bisogno di aspettare niente.

La mia lettura: sui plugin che espongono un input pubblico, cioè commenti, form, prenotazioni e ricerca, l’aggiornamento automatico dovrebbe essere acceso di default, e lo staging va riservato a quelli che toccano checkout e layout. Il rischio di una regressione grafica su un calendario si misura in un pomeriggio, quello di un’esecuzione di codice remoto in un ripristino completo. Ne avevo scritto a proposito delle patch dei plugin e dei bug bounty: la finestra fra correzione e sfruttamento si accorcia, e la difesa che resta sotto il tuo controllo è quanto ci metti ad aggiornare. Il ciclo sopra va lanciato oggi e poi ogni lunedì, con la lista degli alias al posto dei tre esempi.