Patch di sicurezza WordPress: il riepilogo degli aggiornamenti recenti e cosa fare subito

Gli aggiornamenti di sicurezza di WordPress non sono tutti uguali e non vanno trattati tutti allo stesso modo. Una patch che corregge una vulnerabilità di esecuzione di codice remoto su un plugin installato su milioni di siti è un'emergenza che richiede intervento immediato. Una patch che indurisce una funzione interna con bassa esposizione è manutenzione ordinaria che può aspettare il ciclo di aggiornamento programmato. Saper distinguere è la differenza tra gestire la sicurezza e subirla.

Il problema è che WordPress non classifica le proprie patch per gravità in modo esplicito nel canale standard. Le note di release menzionano 'fix di sicurezza e bugfix' insieme, e tocca al gestore del sito capire cosa è critico. Per i plugin del repository la situazione è simile: il changelog descrive la fix, ma la gravità va interpretata dal contesto.

Come leggere una patch di sicurezza

Tre segnali indicano gravità alta. Primo: la descrizione menziona esecuzione di codice remoto, escalation di privilegi o bypass di autenticazione — sono le categorie che permettono a un attaccante di prendere controllo del sito. Secondo: la vulnerabilità è pre-autenticazione, cioè sfruttabile senza essere loggati. Terzo: esiste un proof-of-concept pubblico, il che significa che gli attaccanti hanno già lo strumento per sfruttarla.

Quando tutti e tre i segnali sono presenti, l'aggiornamento è urgente: ore, non giorni. Quando nessuno è presente, è manutenzione e può entrare nel ciclo programmato. La zona grigia — uno o due segnali — richiede giudizio: dipende dall'esposizione del sito, dal tipo di dati che gestisce, e da quanto è targettizzato.

# Checklist rapida: stato aggiornamenti di un sito WordPress
# via WP-CLI (richiede accesso SSH al server)

# 1. Versione core e aggiornamenti disponibili
wp core version
wp core check-update

# 2. Plugin attivi con aggiornamenti disponibili
wp plugin list --status=active --fields=name,version,update_version \
  --format=table | grep -v 'none'

# 3. Tema attivo e sua versione
wp theme status

# 4. Verifica se WPVulnDB segnala vulnerabilità note
# (richiede il plugin WPScan o query API manuale)
wp plugin list --status=active --fields=name,version --format=csv \
  | tail -n +2 | while IFS=, read name version; do
    echo "Checking $name $version..."
    # Query API WPVulnDB per vulnerabilità note
  done

# 5. Dopo l'aggiornamento, verifica di salute
wp core verify-checksums
wp cron event run --due

La regola del backup verificato

Qualunque sia la gravità, prima di aggiornare c'è una regola non negoziabile: il backup deve esistere ed essere verificato. Un backup non testato è un'ipotesi, non un'assicurazione. Aggiornare senza backup verificato significa che se l'aggiornamento rompe il sito, il ripristino diventa un lavoro di ricostruzione, non un'operazione di minuti.

Per le patch critiche la procedura corretta è: backup verificato, aggiornamento in staging, test rapido delle funzioni critiche (login, checkout, form), deploy in produzione, verifica di salute HTTP. Per le patch di manutenzione, la procedura è la stessa ma senza l'urgenza: entra nel ciclo programmato settimanale o mensile. La differenza non è nella procedura, è nel tempo che intercorre tra la disponibilità della patch e il suo deployment. Un check-up di sicurezza include sempre la verifica dello stato degli aggiornamenti e la classificazione di quelli in sospeso.