Plugin WordPress vulnerabili: riconoscerli ed eliminarli

Quando un sito WordPress viene violato, il colpevole è quasi sempre lo stesso: un plugin. Il core viene aggiornato di continuo e controllato da migliaia di occhi, mentre un plugin dimenticato, con tre anni di vita sulle spalle e uno sviluppatore sparito, resta lì per mesi senza che nessuno se ne accorga. Le falle come PHP2Shell fanno notizia, ma nella pratica quotidiana un plugin vecchio è un rischio più concreto e molto più frequente.

In questa guida vediamo come fare un inventario dei plugin dal terminale, come capire quali sono a rischio e come eliminarli senza rompere il sito.

Quali plugin sono davvero a rischio

Un plugin è pericoloso in tre situazioni diverse, e conviene distinguerle perché la soluzione cambia.

Vulnerabile e senza correzione. Esiste una falla pubblica e lo sviluppatore non ha pubblicato l’aggiornamento. Finché non esce, l’unica difesa è disattivare il plugin.

Vulnerabile con correzione disponibile. Il caso più banale e più comune: la patch esiste, ma sul tuo sito non è stata installata. Qui basta aggiornare.

Abbandonato. Nessuna falla nota, ma il plugin non riceve aggiornamenti da molto tempo. Non è ancora un problema oggi, ma lo diventerà alla prima scoperta di una vulnerabilità, perché nessuno la correggerà. Ci sono poi i plugin rimossi dal repository ufficiale, di solito per motivi di sicurezza o perché lo sviluppatore ha chiuso il progetto.

Una quarta categoria va menzionata a parte: i plugin a pagamento scaricati da siti non ufficiali. Le versioni “gratuite” di plugin premium contengono molto spesso codice aggiunto, quindi vanno eliminate senza discussione e sostituite con la licenza originale.

Fare l’inventario con WP-CLI

Il primo passo è sapere cosa c’è installato. Dal terminale, nella cartella del sito:

wp plugin list --fields=name,status,version,update,auto_update

Ottieni nome, stato (attivo o disattivo), versione installata, se è disponibile un aggiornamento e se gli aggiornamenti automatici sono attivi. Per vedere solo quelli che hanno un aggiornamento in attesa:

wp plugin list --update=available --fields=name,version,update_version

Questa lista è la priorità assoluta. Ogni plugin che compare qui ha una versione più recente pronta, e se la differenza è una correzione di sicurezza, ogni giorno in più è un rischio.

Per i plugin disattivati:

wp plugin list --status=inactive --field=name

Un plugin disattivato non esegue codice automaticamente, ma i suoi file restano sul disco e molte falle si possono sfruttare richiamando direttamente un file PHP dall’indirizzo del sito, senza che il plugin sia attivo. Per questo i plugin inutilizzati vanno eliminati, non lasciati spenti.

Se vuoi mettere ordine anche nei file che WP-CLI non elenca, guarda la cartella dei plugin obbligatori:

ls -la wp-content/mu-plugins

I plugin in questa cartella si attivano da soli e non compaiono nel pannello normale. Se ci trovi qualcosa che non hai messo tu, controlla con attenzione.

Controllare l’ultimo aggiornamento di ogni plugin

L’elenco di WP-CLI non dice da quanto tempo un plugin non viene toccato dallo sviluppatore. Per ricavarlo puoi interrogare l’API pubblica di WordPress.org. Serve jq, per leggere i dati:

sudo apt install -y jq

Poi questo script passa in rassegna tutti i plugin installati e stampa per ognuno l’ultima data di aggiornamento e la versione di WordPress per cui è stato testato:

#!/bin/bash
cd /var/www/miosito || exit 1
echo "WordPress installato: $(wp core version)"
echo
printf "%-35s %-12s %-12s %s\n" "PLUGIN" "AGGIORNATO" "TESTATO" "STATO"

for p in $(wp plugin list --field=name); do
  r=$(curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request%5Bslug%5D=$p")
  if echo "$r" | jq -e '.error' >/dev/null 2>&1 || [ -z "$r" ]; then
    printf "%-35s %-12s %-12s %s\n" "$p" "-" "-" "NON NEL REPOSITORY"
  else
    upd=$(echo "$r" | jq -r '.last_updated' | cut -d' ' -f1)
    tst=$(echo "$r" | jq -r '.tested')
    printf "%-35s %-12s %-12s %s\n" "$p" "$upd" "$tst" "ok"
  fi
done

Salvalo, rendilo eseguibile e lancialo. L’output è una tabella semplice. Leggila così:

Ultimo aggiornamento di oltre due anni fa. È il segnale più importante. Un plugin vivo, anche stabile, viene toccato almeno ogni tanto. Un silenzio così lungo indica quasi sempre abbandono.
“Testato” molto indietro rispetto alla tua versione di WordPress. Non vuol dire che non funzioni, ma lo sviluppatore non lo verifica più con le versioni recenti.
“Non nel repository”. Ci sono due spiegazioni possibili: è un plugin a pagamento, che per natura non sta nel repository ufficiale, oppure è stato rimosso. Nel secondo caso devi scoprire il motivo.

Per capire un caso dubbio, apri la pagina wordpress.org/plugins/NOME-DEL-PLUGIN/. Un plugin chiuso mostra un avviso in cima con la data e la causa, che spesso è “problema di sicurezza”. Se vedi quella dicitura, non esistono mezze misure: va rimosso.

Un’avvertenza sullo script: i nomi che WP-CLI restituisce sono le cartelle dei plugin, e in alcuni casi non coincidono con il nome nel repository. Se qualcosa risulta “non trovato” ma sai che è un plugin normale, verifica a mano.

Controllare le vulnerabilità note

L’età di un plugin è un indizio, ma per sapere se esiste una falla pubblicata serve un database di vulnerabilità. Ce ne sono diversi, gestiti da aziende di sicurezza che si occupano di WordPress, come Patchstack, Wordfence e WPScan. Hanno pagine consultabili gratuitamente dove cerchi il nome del plugin e leggi le falle registrate, la versione corretta e la gravità.

Il metodo è semplice. Per ogni plugin importante, cerca il nome nel database e confronta la versione installata con quella in cui la falla è stata corretta. Se la tua versione è precedente, sei esposto. Alcuni di questi servizi offrono anche un accesso per programmi, con limiti sull’uso gratuito, che ti permette di automatizzare il controllo con uno script, e vale la pena se gestisci diversi siti.

Non esiste un controllo automatico perfetto. Un database elenca solo le falle già scoperte e segnalate, quindi un plugin “pulito” nella lista non è per forza sicuro: significa che nessuno ha ancora trovato o dichiarato un problema.

Cosa fare plugin per plugin

Dopo l’inventario, ogni plugin finisce in una di queste situazioni.

Il plugin ha un aggiornamento disponibile. Aggiornalo subito, dopo aver salvato un backup:

wp db export /root/backup/db-$(date +%F).sql
wp plugin update nome-plugin

Se dopo l’aggiornamento qualcosa si rompe, trovi il metodo di diagnosi nella guida su cosa fare quando un aggiornamento di WordPress rompe il sito.

Il plugin non lo usi più. Eliminalo completamente. Il comando uninstall esegue anche la pulizia prevista dal plugin, mentre delete rimuove solo i file:

wp plugin deactivate nome-plugin
wp plugin uninstall nome-plugin

Il plugin serve ma è abbandonato o vulnerabile senza patch. Qui devi trovare un’alternativa. Nel frattempo, se la falla è grave, disattivalo subito: una funzione che manca per un paio di giorni è meglio di un sito violato. Cerca un sostituto che sia mantenuto attivamente, con aggiornamenti recenti e un numero di installazioni alto, e provalo prima su una copia del sito, non su quello online.

Il plugin è una versione piratata. Eliminalo, e poi svolgi un controllo completo del sito, perché potrebbe già aver fatto danni. La procedura per farlo è nella guida su come controllare da terminale se il server è stato infettato.

Dopo l’eliminazione: i residui

Rimuovere un plugin non cancella sempre tutto. Restano a volte tabelle nel database, opzioni e attività pianificate. Guardale così:

PREFIX=$(wp db prefix)
wp db query "SHOW TABLES;" | grep -v "^${PREFIX}\(posts\|postmeta\|options\|users\|usermeta\|comments\|commentmeta\|terms\|termmeta\|term_taxonomy\|term_relationships\|links\)$"
wp cron event list

Il primo comando elenca le tabelle che non appartengono al nucleo di WordPress, quindi quelle create dai plugin. Se ne vedi di un plugin che hai eliminato, puoi cancellarle dopo un backup. Il secondo mostra le attività pianificate: togli quelle che richiamano funzioni di plugin che non esistono più, perché sono righe inutili che producono errori nel log.

Tenere sotto controllo i plugin nel tempo

Il problema non si risolve una volta sola. Un plugin sano oggi può essere abbandonato tra un anno. Qualche abitudine semplice mantiene la situazione sotto controllo.

Aggiornamenti automatici per i plugin critici. WP-CLI permette di attivarli per singolo plugin:

wp plugin auto-updates enable nome-plugin
wp plugin list --fields=name,auto_update

Su un sito per cui l’interruzione costa cara, usali per i plugin molto diffusi e stabili, e aggiorna a mano quelli che toccano pagamenti o funzioni delicate.

Un controllo mensile. Lancia lo script dell’inventario una volta al mese e guarda cosa è cambiato. Ci vogliono cinque minuti.

Meno plugin, meno rischio. Ogni plugin in più è codice in più da mantenere aggiornato. Se una funzione si può ottenere con poche righe nel tema o con una costante in wp-config.php, come quelle descritte nella guida ai comandi per wp-config.php, spesso conviene evitare il plugin.

Compatibilità con PHP. Quando aggiorni la versione di PHP, i plugin vecchi sono i primi a dare problemi. Prima di cambiare, puoi verificare il codice con il PHP Compatibility Checker di BACKdigit. La procedura sicura per aggiornare PHP sul server è nella guida all’aggiornamento di lsphp su OpenLiteSpeed.

Bloccare l’esecuzione di PHP in uploads. Anche se un plugin vulnerabile permette di caricare un file, questa regola impedisce di eseguirlo. È una protezione che copre i casi in cui un plugin sfugge ai tuoi controlli.

Come accorgersi se un plugin è già stato sfruttato

Se hai scoperto che un plugin vulnerabile era attivo da tempo, non basta aggiornarlo. Cerca nei log di accesso le richieste dirette ai suoi file, che di solito partono da indirizzi che non hai mai visto:

grep "/wp-content/plugins/nome-plugin/" /usr/local/lsws/logs/access.log | grep POST | awk '{print $1}' | sort | uniq -c | sort -rn | head

Se compaiono molte richieste POST da pochi indirizzi verso file di quel plugin, qualcuno ci ha provato. A quel punto cerca file PHP modificati o nuovi negli ultimi giorni e procedi con la pulizia, partendo dai passaggi sulle credenziali.

Un’ultima regola

Il criterio più utile da tenere a mente è questo: un plugin deve guadagnarsi il posto sul tuo server. Se lo usi, è aggiornato e il suo sviluppatore risponde, resta. Se non lo usi o non viene più curato, va via. Un sito con dieci plugin tenuti bene è più sicuro di uno con trenta di cui nessuno ricorda l’utilità.