Zero-day WordPress: cosa fare quando esce una vulnerabilità critica

La parola zero-day fa paura, e a ragione: indica una vulnerabilità di cui è già pubblica la prova di concetto, ma per cui non esiste ancora una patch ufficiale. Su WordPress questo succede spesso con i plugin — un ricercatore pubblica un advisory, la notizia si diffonde, e nel giro di ore gli attaccanti automatizzano gli exploit. Se hai quel plugin installato, sei in corsa contro il tempo.

La reazione istintiva è aggiornare tutto subito. È anche la reazione più pericolosa: un aggiornamento di panico in produzione, senza test, può rompere il sito esattamente come lo romperebbe l'attacco. La procedura corretta è diversa e si compone di quattro fasi che vanno eseguite in ordine — valutare, mitigare, patchare, verificare — perché ogni fase riduce il rischio prima della successiva.

Valutare: è davvero esposto il tuo sito?

Il primo passo non è toccare nulla, è capire. Un advisory dice che un plugin è vulnerabile, ma il tuo sito lo usa nella versione vulnerabile? E la funzionalità vulnerabile è attiva? Molti exploit richiedono condizioni specifiche — un utente autenticato, un form attivo, un endpoint REST esposto. Se la tua configurazione non soddisfa quelle condizioni, il rischio è basso e hai tempo per patchare con calma. Se le soddisfa, sei in emergenza.

Puoi fare un primo check rapido della versione installata confrontandola con la versione patchata indicata nell'advisory:

# Verifica rapida della versione di un plugin sospetto via WP-CLI
wp plugin list --status=active --fields=name,version --format=csv

# Confronta con la versione patchata indicata nell'advisory.
# Se la tua versione è < della patchata, sei potenzialmente esposto.

# Controlla se il file vulnerabile è raggiungibile dal web
# (sostituisci con il percorso reale indicato nell'advisory)
curl -s -o /dev/null -w '%{http_code}' \
  https://www.tuosito.com/wp-content/plugins/NOME-PLUGIN/file-vulnerabile.php
# 403/404 = non raggiungibile (bene). 200 = raggiungibile (male).

Mitigare: fermare l'exploit prima della patch

Se il sito è esposto, la patch ufficiale potrebbe non essere ancora disponibile — è la definizione di zero-day. La mitigazione è ciò che fa nel frattempo: bloccare il vettore d'attacco senza aspettare lo sviluppatore del plugin. Il modo più robusto è una regola WAF (Web Application Firewall) che intercetta il pattern dell'exploit prima che raggiunga WordPress. Se usi Cloudflare o un WAF server-side, una regola custom sul pattern della richiesta blocca l'attacco in millisecondi, a livello di edge, senza toccare il sito.

Se non hai un WAF, la mitigazione di emergenza è disabilitare il plugin. Sì, perdi la funzionalità, ma un sito con una funzionalità spenta è infinitamente meglio di un sito compromesso. Disabilitare non significa disinstallare: disattivare il plugin mantiene i dati e permette la riattivazione dopo la patch. Se il plugin è critico per il business (un gateway di pagamento, un form di contatto), la decisione va pesata — ma la regola è che un sito compromesso costa sempre più di una funzionalità temporaneamente spenta.

# Disabilitazione di emergenza di un plugin vulnerabile via WP-CLI
wp plugin deactivate NOME-PLUGIN

# Se il plugin non può essere disattivato (rompe il sito),
# blocca l'endpoint vulnerabile a livello di web server (Nginx):
# location ~* /wp-content/plugins/NOME-PLUGIN/file-vulnerabile.php {
#     deny all;
#     return 403;
# }

# Su Apache (.htaccess):
# <Files "file-vulnerabile.php">
#     Require all denied
# </Files>

# Verifica che il blocco funzioni
curl -s -o /dev/null -w '%{http_code}' \
  https://www.tuosito.com/wp-content/plugins/NOME-PLUGIN/file-vulnerabile.php
# Deve rispondere 403 ora.

Patchare: in staging, mai alla cieca in produzione

Quando la patch esce — a volte in ore, a volte in giorni — l'istinto è installarla subito in produzione. Resisti. La patch corregge la vulnerabilità, ma ogni aggiornamento di plugin può introdurre incompatibilità con il tema o con altri plugin. La procedura corretta è: installa la patch in staging, verifica che il sito funzioni, poi rilascia in produzione. Se l'emergenza è alta e non hai staging, almeno fai un backup verificato immediato prima di aggiornare, così puoi tornare indietro se la patch rompe qualcosa.

Il caso peggiore è la patch che non esiste perché lo sviluppatore ha abbandonato il plugin. Lì la decisione è definitiva: trovare un plugin alternativo che faccia la stessa cosa, o sviluppare una soluzione custom. Mantenere un plugin abbandonato e vulnerabile non è un'opzione — è una bomba a orologeria. Un audit di sicurezza periodico individua i plugin abbandonati prima che diventino emergenze zero-day.

Verificare: il sito è davvero pulito?

Se il sito era esposto e c'è il sospetto che sia stato sfruttato prima della mitigazione, la patch non basta: serve una verifica di compromissione. Un exploit riuscito può aver lasciato una backdoor — un file PHP nascosto, una riga iniettata in un file del tema, un nuovo utente amministratore. La verifica confronta i file del sito con una copia pulita e cerca modifiche non autorizzate, nuovi file sospetti, e account amministrativi non riconosciuti.

# Verifica post-incidente: confronta i file con una copia pulita

# 1. Cerca file PHP modificati di recente (ultimi 7 giorni)
find /var/www/wordpress -name '*.php' -mtime -7 -type f

# 2. Cerca nuovi utenti amministratori non riconosciuti
wp user list --role=administrator --fields=ID,user_login,user_email,registered_date

# 3. Cerca stringhe sospette nei file del tema (base64, eval, gzinflate)
grep -rn 'eval\|base64_decode\|gzinflate\|str_rot13\|strrev' \
  wp-content/themes/ --include='*.php' | head -20

# 4. Confronta i checksum dei file core con quelli ufficiali
wp core verify-checksums
# Se restituisce 'Warning: File non corrisponde', il core è stato modificato.

Una risposta zero-day collaudata non è improvvisata al momento: è una procedura scritta, con responsabilità assegnate e strumenti già pronti (WAF, staging, backup, WP-CLI). Quando l'advisory arriva — e arriverà — il sito che ha la procedura si salva in ore; il sito che non ce l'ha scopre l'attacco settimane dopo, quando i danni sono fatti. Un piano di sicurezza gestito include questa procedura come standard: noi valutiamo, mitighiamo, patchiamo e verifichiamo, tu continui a lavorare.