Home Chi Sono
Servizi ▼
WordPress Sviluppo Web Server & Hosting Assistenza Tecnica Windows Android
Blog ▼
Tutti gli Articoli WordPress Hosting Plesk Assistenza Computer Windows Android A.I.
Contatti

Come Faccio l’Audit Completo dei Plugin WordPress per Eliminare le Vulnerabilità: La Mia Procedura di Sicurezza 2026

Se gestisci siti WordPress come me, il dato che sto per darti ti farà riflettere: nel 2026, vengono scoperte in media oltre 250 nuove vulnerabilità nei plugin WordPress ogni settimana. Solo nella prima settimana di gennaio 2026 ne sono emerse 333, di cui 253 riguardanti plugin e 80 temi. Il dettaglio peggiore? Il 71% di queste vulnerabilità risultava ancora senza patch al momento della divulgazione. Numeri che ho verificato personalmente monitorando i report settimanali di SolidWP e Patchstack.

Dopo anni passati a gestire server Plesk e a mettere in sicurezza installazioni WordPress per clienti e progetti personali, ho sviluppato una procedura di audit dei plugin che eseguo regolarmente. Non si tratta solo di aggiornare tutto e sperare per il meglio: è un processo sistematico che parte dall’inventario, passa per la scansione delle vulnerabilità note, e arriva fino all’eliminazione di tutto il codice superfluo. In questo articolo vi mostro esattamente come faccio.

Se avete già letto la mia guida su come mettere in sicurezza WordPress dagli attacchi brute force, sapete che la sicurezza è un tema che mi sta molto a cuore. L’audit dei plugin è il passo successivo — e probabilmente il più importante — per proteggere davvero un sito WordPress nel 2026.

Perché l’Audit dei Plugin WordPress È Fondamentale nel 2026

La superficie d’attacco di WordPress nel 2026 è dominata dai plugin. Secondo i dati aggregati più recenti, l’88% delle vulnerabilità WordPress è riconducibile ai plugin, il 12% ai temi e praticamente lo 0% al core. Le tipologie predominanti sono Cross-Site Scripting (XSS) al 39% e Broken Access Control al 24%. Il dato che più mi preoccupa è che circa il 42% delle vulnerabilità scoperte nel 2026 resta senza patch.

Per darvi un esempio concreto: a febbraio 2026 è stata divulgata una vulnerabilità critica nel plugin WPvivid Backup & Migration (CVE-2026-1357), con score CVSS di 9.8, che permetteva l’esecuzione di codice remoto senza autenticazione su oltre 900.000 siti. Ho immediatamente verificato tutte le installazioni che gestisco e aggiornato alla versione 0.9.124. Sempre a febbraio, il plugin wpForo Forum (CVE-2026-0910) presentava una falla di PHP Object Injection che consentiva il takeover del sito partendo da un semplice account Subscriber.

Questi casi dimostrano perché non basta “aggiornare quando capita”: serve una procedura strutturata di audit.

Step 1: Inventario Completo dei Plugin Installati

Il primo passo della mia procedura è generare un inventario completo di tutti i plugin presenti sull’installazione. Uso WP-CLI direttamente dalla shell del server (Plesk mi dà accesso SSH su tutti i domini):

# Lista tutti i plugin con versione e stato
wp plugin list --format=table

# Esporta in CSV per archivio
wp plugin list --format=csv > /home/backup/plugin-audit-$(date +%Y%m%d).csv

Questo mi dà una visione chiara di:

  • Quanti plugin sono installati (attivi e inattivi)
  • Quale versione è in uso
  • Se ci sono plugin disattivati ma ancora presenti nel filesystem
  • Plugin must-use (mu-plugins) che spesso vengono dimenticati

Regola d’oro: ogni plugin installato aumenta la superficie d’attacco, anche se disattivato. Il codice è comunque raggiungibile dal web se non si prendono precauzioni a livello server.

Step 2: Identificare ed Eliminare Plugin Abbandonati

Un plugin non aggiornato da oltre 2 anni è considerato abbandonato dalla community WordPress.org. Nella mia esperienza, questi plugin sono le mine antiuomo della sicurezza WordPress: nessuno li patcherà mai, ma gli attaccanti conoscono benissimo le loro vulnerabilità.

Per identificarli controllo:

  1. La data dell’ultimo aggiornamento su wordpress.org/plugins
  2. Il numero di problemi di supporto aperti senza risposta
  3. Se il plugin è stato rimosso dal repository ufficiale
  4. Se lo sviluppatore ha altri progetti attivi

Se un plugin è abbandonato, lo rimuovo immediatamente e cerco un’alternativa mantenuta attivamente. Se non esiste un’alternativa, valuto se la funzionalità è davvero necessaria o se posso implementarla con codice custom nel functions.php del tema child.

Step 3: Scansione Vulnerabilità con WPScan CLI

Il cuore del mio audit è WPScan, lo scanner a riga di comando che interroga il database di vulnerabilità WordPress più completo disponibile. Lo uso dalla shell del mio server (è preinstallato su Kali, ma si installa facilmente ovunque con Ruby):

# Scansione base con API token per dati vulnerabilità
wpscan --url https://miosito.it --api-token IL_TUO_TOKEN --enumerate vp,vt

# Scansione aggressiva di tutti i plugin
wpscan --url https://miosito.it --api-token IL_TUO_TOKEN --plugins-detection aggressive

# Enumerazione utenti (verifica esposizione username)
wpscan --url https://miosito.it --enumerate u

WPScan funziona come un black box scanner: simula un attaccante esterno e verifica versioni di WordPress, plugin e temi contro il suo database di vulnerabilità note. Il piano gratuito offre 25 richieste API al giorno, sufficienti per la maggior parte dei siti (una richiesta per WordPress + una per ogni plugin/tema).

All’inizio non funzionava come mi aspettavo perché il WAF del server bloccava le richieste di WPScan. Ho dovuto temporaneamente whitelistare l’IP del mio scanner nelle regole di Fail2Ban che avevo configurato su Plesk. Un dettaglio che molti dimenticano.

Alternativa: WP-CLI Vulnerability Scanner

Per chi preferisce restare dentro l’ecosistema WP-CLI, c’è un ottimo pacchetto di 10up che interroga i database di WPScan, Patchstack o Wordfence Intelligence:

# Installazione
wp package install 10up/wpcli-vulnerability-scanner:dev-stable

# Scansione completa
wp vuln status

# Output in JSON per automazione
wp vuln status --format=json

Lo trovo perfetto per integrarlo nei cronjob automatizzati su Plesk e ricevere report periodici via email.

Step 4: Audit dei Permessi e delle Capability

Molte vulnerabilità del 2026 sfruttano il Broken Access Control: plugin che non verificano correttamente i permessi utente. Un esempio recente è il CVE-2026-1671 del plugin WP System Log, dove un utente con ruolo Subscriber poteva accedere ai log di sistema contenenti dati sensibili.

Nella mia procedura verifico sempre:

  • Che la registrazione utenti sia disabilitata se non necessaria
  • Che il ruolo predefinito sia impostato su Subscriber (mai su Editor o superiore)
  • Che non esistano account dormienti con privilegi elevati
  • Che ogni plugin che gestisce form, upload o AJAX abbia controlli di capability adeguati
# Verifica utenti con ruolo amministratore
wp user list --role=administrator --format=table

# Cerca utenti creati di recente (potenziali backdoor)
wp user list --orderby=registered --order=desc --format=table

Come ho spiegato anche nell’articolo sulla gestione dei permessi su Android, il principio del least privilege vale ovunque: ogni utente e ogni plugin devono avere solo i permessi strettamente necessari.

Step 5: Verifica Integrità File e Malware Scan

Dopo la scansione delle vulnerabilità note, passo alla verifica dell’integrità dei file. WordPress ha un meccanismo built-in che pochi conoscono:

# Verifica integrità del core WordPress
wp core verify-checksums

# Verifica checksum dei plugin dal repository
wp plugin verify-checksums --all

Questi comandi confrontano i file presenti sul server con quelli originali del repository. Qualsiasi differenza potrebbe indicare una modifica non autorizzata o un’iniezione di codice malevolo.

Per una scansione malware più approfondita, uso Wordfence (versione free) direttamente dal pannello WordPress, che esegue scansione basata su firme e analisi comportamentale. Lo affianco a controlli manuali lato server:

# Cerca file PHP modificati di recente (ultimi 7 giorni)
find /var/www/vhosts/miosito.it/httpdocs/wp-content/ -name "*.php" -mtime -7

# Cerca pattern sospetti nei file PHP
grep -r "eval(base64_decode" /var/www/vhosts/miosito.it/httpdocs/wp-content/plugins/
grep -r "exec(" /var/www/vhosts/miosito.it/httpdocs/wp-content/plugins/

Step 6: Implementare Protezione Proattiva Post-Audit

L’audit non serve a nulla se non si mettono in atto misure preventive per il futuro. Ecco cosa configuro sempre dopo un audit completo:

Aggiornamenti Automatici Selettivi

// In wp-config.php - abilita auto-update per plugin di sicurezza
define('WP_AUTO_UPDATE_CORE', 'minor');

// In functions.php del tema child
add_filter('auto_update_plugin', function($update, $item) {
    // Lista plugin da aggiornare automaticamente
    $auto_update_plugins = array(
        'wordfence/wordfence.php',
        'sucuri-scanner/sucuri.php',
    );
    if (in_array($item->plugin, $auto_update_plugins)) {
        return true;
    }
    return $update;
}, 10, 2);

Hardening del wp-content

# Blocca esecuzione PHP nelle directory uploads (Nginx su Plesk)
location ~* /wp-content/uploads/.*.php$ {
    deny all;
}

# Proteggi directory mu-plugins
location ~* /wp-content/mu-plugins/.*.php$ {
    internal;
}

Queste direttive Nginx le aggiungo dalla configurazione personalizzata di Plesk, seguendo lo stesso approccio che uso per ottimizzare le performance con Brotli su Nginx e per abilitare HTTP/3 QUIC su Plesk.

Monitoring Continuo con WP Activity Log

Installo WP Activity Log su ogni sito che gestisco. Questo plugin registra ogni azione rilevante per la sicurezza: login, logout, tentativi falliti, modifiche a post, installazione plugin e cambi di configurazione. Lo considero essenziale per la forensics post-incidente e per il monitoraggio in tempo reale.

Step 7: Creare lo Script di Audit Automatizzato

Per rendere tutto ripetibile, ho creato uno script bash che eseguo come cronjob settimanale su Plesk:

#!/bin/bash
# audit-wp-plugins.sh - Audit settimanale plugin WordPress
# Autore: Dario Iannascoli

SITE_PATH="/var/www/vhosts/miosito.it/httpdocs"
REPORT_DIR="/home/backup/audit-reports"
DATE=$(date +%Y%m%d)
EMAIL="admin@miosito.it"

mkdir -p $REPORT_DIR

echo "=== AUDIT PLUGIN WORDPRESS - $DATE ===" > $REPORT_DIR/audit-$DATE.txt

# 1. Lista plugin
cd $SITE_PATH
wp plugin list --format=table >> $REPORT_DIR/audit-$DATE.txt 2>&1

# 2. Verifica checksum core
echo -e "n=== VERIFICA INTEGRITÀ CORE ===" >> $REPORT_DIR/audit-$DATE.txt
wp core verify-checksums >> $REPORT_DIR/audit-$DATE.txt 2>&1

# 3. Verifica checksum plugin
echo -e "n=== VERIFICA INTEGRITÀ PLUGIN ===" >> $REPORT_DIR/audit-$DATE.txt
wp plugin verify-checksums --all >> $REPORT_DIR/audit-$DATE.txt 2>&1

# 4. Scansione vulnerabilità (richiede 10up/wpcli-vulnerability-scanner)
echo -e "n=== SCANSIONE VULNERABILITÀ ===" >> $REPORT_DIR/audit-$DATE.txt
wp vuln status >> $REPORT_DIR/audit-$DATE.txt 2>&1

# 5. Cerca file sospetti
echo -e "n=== FILE PHP MODIFICATI ULTIMI 7 GIORNI ===" >> $REPORT_DIR/audit-$DATE.txt
find $SITE_PATH/wp-content/ -name "*.php" -mtime -7 >> $REPORT_DIR/audit-$DATE.txt 2>&1

# Invia report via email
mail -s "[AUDIT WP] Report settimanale - $DATE" $EMAIL < $REPORT_DIR/audit-$DATE.txt

Lo schedulo nei cronjob di Plesk ogni lunedì mattina alle 6:00. Se il report evidenzia anomalie, intervengo immediatamente.

Checklist Rapida per l’Audit Plugin WordPress

Ecco la mia checklist sintetica che stampo e tengo sulla scrivania:

  1. Inventario: esporta lista completa plugin con versioni
  2. Pulizia: elimina plugin inattivi, abbandonati e duplicati
  3. Scansione CVE: verifica ogni plugin contro database vulnerabilità
  4. Aggiornamenti: applica tutte le patch disponibili
  5. Permessi: verifica ruoli utente e capability
  6. Integrità: controlla checksum core e plugin
  7. Malware: scansione file sospetti e pattern malevoli
  8. Hardening: blocca esecuzione PHP in uploads, proteggi wp-config
  9. Monitoring: attiva logging e notifiche
  10. Backup: verifica che il backup remoto su Wasabi sia aggiornato e funzionante

FAQ

Ogni quanto devo fare l’audit dei plugin WordPress?

Nella mia esperienza, un audit completo va eseguito almeno una volta al mese, con scansioni automatiche settimanali. Dopo ogni aggiornamento major di WordPress o dopo l’installazione di nuovi plugin, eseguo sempre un audit aggiuntivo. Con oltre 250 nuove vulnerabilità scoperte ogni settimana nel 2026, la frequenza è fondamentale.

Posso fare l’audit dei plugin senza accesso SSH al server?

Sì, ma con limitazioni. Puoi usare plugin come Wordfence o Sucuri Security direttamente dal pannello WordPress per scansioni malware e vulnerabilità. Tuttavia, per un audit completo raccomando l’accesso SSH con WP-CLI e WPScan: la visibilità lato server è incomparabile rispetto ai soli strumenti da dashboard.

I plugin disattivati sono un rischio di sicurezza?

Assolutamente sì. Un plugin disattivato resta fisicamente sul server e il suo codice PHP può essere raggiunto direttamente via URL, senza passare dal bootstrap di WordPress. Se quel codice ha una vulnerabilità, un attaccante può sfruttarla. La regola è semplice: se non lo usi, cancellalo.

WPScan è gratuito? Quante scansioni posso fare?

WPScan CLI è gratuito per uso non commerciale. Il piano free dell’API offre 25 richieste al giorno: una per la versione WordPress, una per ogni plugin e una per ogni tema. Considerando che il sito medio ha circa 22 plugin, il piano gratuito copre la maggior parte delle esigenze per un singolo sito.

Cosa faccio se trovo un plugin vulnerabile senza patch disponibile?

Questo è lo scenario peggiore e più frequente: nel 2026 circa il 42% delle vulnerabilità resta senza fix. La mia procedura è: 1) disattivare e rimuovere immediatamente il plugin, 2) cercare un’alternativa mantenuta, 3) se il plugin è critico, implementare virtual patching tramite regole WAF personalizzate su Nginx o con un servizio come Patchstack. Nel frattempo, monitoro i log per segni di compromissione.

Conclusione: L’Audit dei Plugin WordPress Non È Opzionale

Con 1.558 vulnerabilità WordPress censite nel 2026, l’88% delle quali nei plugin, fare un audit completo dei plugin WordPress non è più un’opzione: è una necessità operativa. La procedura che vi ho mostrato — dall’inventario alla scansione, dall’hardening al monitoring automatizzato — è quella che uso quotidianamente per proteggere i siti che gestisco.

Il concetto chiave è la difesa in profondità: non basta un singolo plugin di sicurezza. Serve combinare strumenti lato server (WPScan, Fail2Ban, regole Nginx), plugin WordPress dedicati (Wordfence, WP Activity Log) e buone pratiche operative (aggiornamenti tempestivi, principio del minimo privilegio, backup verificati).

Se questo articolo vi è stato utile, vi consiglio anche la mia guida su come proteggere WordPress dai brute force e quella sulla configurazione di Fail2Ban su Plesk. La sicurezza è un processo continuo, non un traguardo. Avete domande sulla vostra procedura di audit? Scrivetemi nei commenti!

Share: