Fai un audit di WordPress? Inizia dai tuoi plugin

Summary

La maggior parte degli audit di sicurezza di WordPress sono al contrario: enfatizzano gli aggiornamenti del core e i rapporti degli scanner, mentre le vulnerabilità che realmente colpiscono vivono nei plugin. Un white paper SANS ha rilevato che oltre il 96% delle vulnerabilità dell'ecosistema ha origine in plugin di terze parti e circa il 43% non richiede autenticazione. Questo articolo illustra un audit incentrato sui plugin per un piccolo team di marketing interno, usando la storia di un sito che è stato hackerato perché tutti scansionavano il livello sbagliato. Imparerai a inventariare e classificare ogni plugin, testare le superfici di attacco non autenticate, rivedere manualmente utenti e log e tradurre i risultati in un linguaggio di rischio che un capo non tecnico capisce. Il risultato è un rituale di triage trimestrale invece di un esercizio da checklist.

La maggior parte degli audit di sicurezza di WordPress sono teatro. Passi un pomeriggio ad aggiornare il core, cambiare la password admin e lanciare uno scanner di plugin che riporta con orgoglio "Nessun problema critico." Nel frattempo, il plugin che accettava caricamenti di file e che è stato aggiornato l'ultima volta tre anni fa resta tranquillo nella tua directory uploads, in attesa di qualcuno che non è nella lista degli invitati.

I numeri lo confermano. Un white paper SANS sulla scansione dei plugin di WordPress ha rilevato che oltre il 96% delle vulnerabilità dell'ecosistema ha origine in plugin di terze parti, con i temi al 4% e il core sotto l'1%. Circa il 43% di questi difetti può essere sfruttato senza alcuna autenticazione. Quindi quando il tuo audit spende la maggior parte delle energie sul core, stai esaminando gli alberi mentre un incendio boschivo divampa nella directory dei plugin accanto.

Non è un invito al panico sul core. Le vulnerabilità del core come i difetti RCE di wp2shell che hanno ricevuto exploit pubblici di recente dovrebbero essere corrette il giorno in cui vengono annunciate. Ma sono abbastanza rare da non meritare la maggior parte delle ore del tuo audit. La maggior parte appartiene ai plugin, ed è lì che inizia il vero processo.

Immagina lo scenario precedente: una domenica mattina, il tuo sito reindirizza a una pagina di casinò e il tuo capo scrive via email "Pensavo che avessimo la sicurezza." Avevi la sicurezza — avevi un audit da checklist. Lo scenario successivo è un sistema di triage che tratta i plugin come la superficie di attacco che realmente sono, li testa dall'esterno e controlla le cose che gli scanner non possono vedere.

Fai parte di un piccolo team di marketing con un sito WordPress attivo dal 2017. Ha un plugin personalizzato di registrazione a eventi creato da un freelance nel 2019, un plugin per moduli di contatto con campo di caricamento file e un plugin slider che è stato venduto e non ha più una pagina pubblica di aggiornamenti. Non è uno stack insolito. È qui che inizia il tuo audit.

---

L'inventario dei plugin è la tua politica di sicurezza

Fai l'inventario di ogni plugin e tema. Annota la versione, la data dell'ultimo aggiornamento, se il fornitore è ancora attivo e se qualcuno lo usa davvero. Poi classifica ciascuno in una categoria: mantenuto e usato, mantenuto e non usato, abbandonato ma usato, abbandonato e non usato. Rimuovi subito quelli non usati. Ignora la difesa "sono solo $50 al mese" — un plugin non usato è una responsabilità, non una funzionalità. Per quelli abbandonati ma usati, decidi: sostituiscilo o accetta il rischio e scrivilo in un registro dei rischi che il tuo capo abbia visto.

Il plugin di registrazione eventi rientra nella categoria abbandonato ma usato. Accetta pagamenti e invia email di conferma, e sostituirlo è un progetto, quindi per ora lo tieni. Ma scrivi una nota che dice "questa è la fonte più probabile di una futura violazione" e lo aggiungi in cima alla lista dei test.

Superficie di attacco	Quota delle vulnerabilità note di WordPress	Priorità di audit
Plugin di terze parti	Oltre il 96%	Massima — inventario, scansione, test, sostituzione
Temi	Circa il 4%	Media — solo se personalizzati o obsoleti
Core di WordPress	Sotto l'1%	Bassa — mantieni aggiornato e vai avanti

Quando SecurityWeek ha contato più di 8.000 nuove vulnerabilità di WordPress nel 2024, la stragrande maggioranza era di questo tipo: problemi di plugin, non patch del core. Uno scanner ti dirà quelle che sono state divulgate e a cui è stato assegnato un CVE. Non ti dirà del codice personalizzato del freelance senza CVE, perché nessuno l'ha mai esaminato attentamente. Quella revisione manuale è compito tuo. Per un approfondimento sui controlli specifici dei plugin, vedi questa guida su come fare audit dei tuoi plugin WordPress per vulnerabilità.

---

Testalo come un estraneo: il 43% che non richiede password

Il tuo scanner ti ha già detto che non c'è nulla di sbagliato. Ora fai ciò che non può fare: sonda il sito dall'esterno, senza login. Inizia da ogni campo di caricamento file, ogni modulo che elabora una POST, ogni endpoint admin-ajax. Il caricamento controlla effettivamente il contenuto del file, o solo l'estensione? Dove finiscono i file caricati e il server web può eseguire PHP in quella directory? Il 43% dei difetti dei plugin che non richiedono autenticazione di solito si trova esattamente in questi punti: XSS persistente non autenticato, caricamento arbitrario di file e iniezione di oggetti PHP.

Il plugin del modulo di contatto consente ai visitatori di allegare un curriculum. Rinomina il file usando il nome originale del visitatore, quindi carichi "resume.php" e lo salva in una cartella /uploads/contact/ che è scrivibile per progettazione. Se il server permette anche di eseguire PHP in quella directory, l'attaccante ha appena ottenuto una webshell. Fastly ha documentato lo sfruttamento attivo di XSS persistente non autenticato nei plugin WordPress — non è un rischio di nicchia da slide. Il tuo test è semplice: crea un file con contenuto noto, caricalo e verifica se torna con il suo nome e tipo originali. Poi prova a caricare un file .php. Se torna come .php, hai appena trovato un buco sfruttabile.

È anche qui che l'argomento "ma il nostro plugin di sicurezza ha un WAF" crolla. Un WAF può bloccare un payload noto, ma le regole di normalizzazione dei percorsi su cui si basa spesso divergono da ciò che il server fa realmente. La guida OWASP Web Security Testing è un riferimento migliore di qualsiasi dashboard: descrive come testare in modo metodico i difetti di caricamento file e l'XSS persistente. E se scopri che il plugin è abbandonato, è il momento di applicare il protocollo di pulizia: il pericolo nascosto dei plugin WordPress abbandonati spiega perché lasciare un'estensione morta in posizione è peggio che rimuoverla e adattare il tuo flusso di lavoro.

---

Ciò che lo scanner non può vedere: utenti, log e vecchio codice

I test dinamici catturano ciò che è esposto in questo momento. La revisione manuale cattura ciò che è già dentro. Inizia con gli account utente: apri l'elenco admin e cerca account che non hai creato tu. Un admin chiamato "support" con un indirizzo di posta gratuita e nessun essere umano dietro è una backdoor, non un collega. Controlla i timestamp dei file in wp-content/uploads per qualsiasi cosa modificata di recente che non sia contenuto tuo. Controlla il log di accesso del server per richieste che assomigliano a un comando curl di un bot piuttosto che al browser di una persona.

Il plugin eventi ha un caricamento "foto relatore" che salva in uploads/event-headshots/. Durante il test trovi un file che non è tuo — un piccolo file PHP con un nome dall'aspetto casuale. Questa è la tua webshell. È arrivata lì attraverso lo stesso difetto di caricamento che hai testato due settimane fa, e ormai uno scanner non la "vedrebbe" comunque perché non è una vulnerabilità del plugin; è una prova di vulnerabilità. La revisione manuale la trova, la elimina e controlla il log per l'indirizzo IP che l'ha inserita. Invicti ha notato che l'iniezione di oggetti PHP nei plugin è in aumento ed è quasi invisibile alle scansioni black-box perché l'oggetto malizioso si materializza solo durante l'esecuzione. L'unico modo per individuarla è leggere il codice per pattern pericolosi come chiamare unserialize() su input forniti dall'utente. Leggere qualche centinaio di righe del plugin personalizzato costa meno che pagare una parcella per una risposta a incidenti.

È anche qui che il consiglio standard di "installa semplicemente più plugin di sicurezza" raggiunge il suo limite. Impilare tre plugin di sicurezza ti dà regole WAF sovrapposte che si bloccano a vicenda, un torrente di email di log duplicate e l'occasionale errore "sei bannato" sul tuo stesso login admin. Un plugin di sicurezza attivo, ben configurato, è sufficiente. Leggi perché troppi plugin di sicurezza si ritorcono contro prima di aggiungere qualsiasi altra cosa al mucchio.

---

Dire la verità al tuo capo senza scatenare il panico

Al tuo capo non interessano i punteggi CVSS o l'iniezione di oggetti PHP. Gli interessa che il sito vada giù, che il negozio non prenda ordini e il budget IT. La traduzione è semplice: "Questo plugin ha un difetto noto di esecuzione remota di codice non autenticata. Un estraneo può eliminare il contenuto del nostro sito o installare una backdoor. Dobbiamo sostituirlo entro questo trimestre." Poi mostra la lista delle priorità: sostituisci il plugin eventi, disabilita il caricamento file del modulo di contatto finché non valida correttamente i tipi di file, ruota tutte le credenziali admin e programma la prossima revisione trimestrale.

Hai anche un vantaggio linguistico: CISA mantiene il catalogo Known Exploited Vulnerabilities, che ti dice esattamente quali difetti pubblicati vengono sfruttati attivamente nel mondo reale. Se uno dei tuoi plugin compare lì, l'argomento non è più teorico — esiste un exploit noto e sei sotto scadenza. Se non compaiono, usalo comunque come standard per definire cosa significa "urgente". Il monitoraggio di CISA rende più facile convincere un capo non tecnico che non si tratta di una email di phishing; è un database pubblico di ciò che gli attaccanti stanno facendo proprio ora. Quando il trimestre finisce, avrai un flusso di lavoro per la remediation, non un esercizio una tantum da checklist. Un workflow per trasformare le vulnerabilità in un ciclo di patch mantiene viva l'abitudine.

---

Il prima era un sito rotto, un'email frenetica e un rapporto dello scanner pulito che diceva che non c'era nulla di sbagliato. Il dopo è un rituale trimestrale: inventario, classificazione, test dall'esterno, revisione di utenti e log e scrittura delle decisioni prese e dei rischi accettati. Lo scanner diventa una mappa di dove guardare, non un certificato di salute. I plugin diventano un elenco che conosci per nome. E la prossima volta che il tuo capo chiederà dell'audit, avrai una risposta che non richiede di incrociare le dita.