Hosting WordPress sicuro: il pentest che smaschera il marketing

Tre settimane fa ho aperto il sito di un negozio WooCommerce arrivato da un passaparola. Hosting premium, 480€ l'anno, homepage piena di badge sulla «sicurezza avanzata» e sul «firewall gestito». Il checkout aveva uno skimmer agganciato da almeno quattro settimane, iniettato da un plugin di sicurezza che non riceveva aggiornamenti da otto mesi. Il proprietario pagava per una promessa. Nessuno gli aveva mai chiesto come quella promessa venisse mantenuta, a partire da lui.

Questa storia mi è tornata in mente leggendo cosa è emerso a WordCamp Europe 2026. Maciek Palmowski, di Patchstack, ha presentato un lavoro dal titolo molto diretto: Testing the promise, does secure hosting deliver? Ha poi raccontato i dettagli nell'episodio 227 del podcast di WP Tavern, e vale la pena ricostruirlo con la mia ottica di consulente: cosa è stato testato, cosa è venuto fuori, e cosa dovreste fare domattina se state pagando per un hosting WordPress sicuro senza sapere cosa questo titolo copre davvero.

Cosa ha testato Patchstack, in concreto

Il metodo conta più delle conclusioni, quindi partiamo da lì. Il team ha preso 30 vulnerabilità note di plugin WordPress, scelte tra quelle che si incontrano davvero nel mondo reale, e le ha riprodotte contro un campione di provider che si pubblicizzano come hosting sicuro. Stessa metodologia per tutti, attacchi standardizzati, risultati validati da osservatori indipendenti per evitare che ogni vendor interpretasse i numeri a proprio favore.

Il risultato riassunto in una frase: la maggioranza degli attacchi specifici WordPress passa lo stesso. Non «qualche eccezione», non «in casi limite»: la maggioranza. Se vendete sicurezza e il test dice che più della metà degli attacchi arriva a bersaglio, il problema non è più marketing. È ingegneria che non tiene quello che la brochure scrive.

Il dettaglio più interessante, però, è un altro. Ci sono provider con la stessa identica dotazione di strumenti — stesso WAF, stesso scanner, stesse regole — che ottengono esiti opposti nel test. La conclusione di Palmowski è che non conta solo quali strumenti usi, ma come li usi. Le regole del WAF chi le scrive, con che velocità le aggiorna quando esce un 0-day, chi tiene d'occhio i falsi positivi su WooCommerce: sono questi i punti dove la sicurezza reale si separa da quella stampata nella landing page.

Il modello svizzero e il buco del marketing

Durante l'intervista viene citato il modello svizzero del formaggio: ogni layer di difesa ha dei buchi, e l'idea è sovrapporli così che i buchi di uno vengano coperti da un altro. È un'immagine che uso io stesso con i clienti da anni, ma i provider la interpretano in modo conveniente: la loro fetta di formaggio è il WAF, e vi vendono quella dimenticando che il vostro sito ne ha almeno altre quattro.

Nel caso dello skimmer del mio cliente, la catena era: plugin non aggiornato, patch di sicurezza non applicata per mancanza di manutenzione, WAF che non conosceva quel pattern di iniezione, nessun monitoraggio del checkout. Quattro buchi allineati. Il provider puntava il dito sul plugin, il plugin puntava il dito sull'hosting. Il cliente nel mezzo, con 480€ spesi e un sito che rubava carte di credito. Dopo una settimana di pulizia e ricostruzione abbiamo fatto passare la manutenzione a noi, con un piano di assistenza WordPress che include proprio quello che manca a quasi tutti gli hosting: la parte applicativa.

Le domande giuste da fare al provider

Il test di Patchstack nasce per creare una conversazione più matura: se il marketing non basta, serve una lista di domande che smascherino la sostanza. Le uso io in versione ridotta, e funzionano sia con un host enterprise che con il managed da 9€ al mese:

• Patch velocity del WAF: quando esce una nuova CVE famosa, in quanto tempo le vostre regole la coprono? Chiedete un numero, non un aggettivo.
• Chi risponde agli 0-day: c'è un team interno o il firewall si aggiorna solo quando il vendor rilascia? Le due cose si chiamano allo stesso modo nelle brochure.
• Isolamento tra account: su un shared, quando un vicino viene compromesso, cosa protegge il mio account? Chiedete come sono configurati l'isolamento e i permessi a livello filesystem.
• Log e forensics: in caso di incidente, chi conserva i log, per quanto tempo, e chi li legge? Se la risposta è «i log ci sono», non è una risposta.
• Restore testato: i backup esistono, ma quando è stato testato l'ultimo restore completo? Su richiesta, non promessa.

A queste domande aggiungo sempre la mia: «fammi vedere l'ultima CVE che avete mitigato in virtual patching, con data». Chi lavora seriamente la mostra in due minuti. Chi improvvisa comincia a parlare di SLA.

Il test da 15 minuti che puoi fare da solo

Il provider risponde alle domande, bene. Ma metà del pericolo sta sul tuo sito, non sui suoi server. Questo è il test che eseguo su ogni nuovo cliente in un quarto d'ora, con WP-CLI:

# plugin e temi senza aggiornamenti: i veri responsabili della maggior parte dei breach
wp plugin list --update=none --field=name --allow-root
# chi ha capacità admin e quando ha toccato il sito l'ultima volta
wp user list --role=administrator --fields=ID,user_login,last_update --allow-root
# file PHP modificati negli ultimi 14 giorni: i candidati skimmer
find wp-content -name "*.php" -mtime -14 | head -20

Tre comandi, tre risposte. Se il primo elenco è lungo, la vostra superficie d'attacco è lunga. Se il secondo ha più di tre amministratori, qualcuno non dovrebbe essere lì. Se il terzo restituisce file che nessuno del vostro team ha toccato, avete un problema in corso, non potenziale. A quel punto non serve un pentest: serve l'emergenza.

L'AI sta accelerando entrambi i lati della barricata

Nel podcast Palmowski tocca anche un punto che merita spazio a sé: l'intelligenza artificiale sta aumentando velocità e sofisticazione degli attacchi, e lo fa in parallelo dall'altra parte della rete, dove serve a scrivere regole di difesa più in fretta. Il risultato pratico per chi gestisce siti è uno solo: il tempo tra la pubblicazione di una vulnerabilità e il suo sfruttamento attivo si sta accorciando. L'abbiamo visto a fine agosto con All-in-One WP Migration: patch disponibile da settimane, e una fetta enorme dei 3,25 milioni di siti esposti che non l'aveva ancora applicata. Se la finestra si accorcia, la domanda «aggiorno stasera o domani?» smette di essere una questione di comfort. Diventa la differenza tra un aggiornamento di routine e un incidente con il sito offline.

Per un provider tutto questo si traduce in patch velocity misurabile, quella di cui parlavamo prima. Per voi si traduce in una cosa semplice: i plugin esposti sul front-end — form, checkout, pagamenti — vanno chiusi entro ore, non settimane. È uno dei motivi per cui il piano di assistenza WordPress che proponiamo prevede una soglia di intervento urgente per le CVE critiche: il calendario umano non regge più il ritmo delle CVE, e chi lo negozia a mano perde.

Quando l'hosting «sicuro» non basta: il caso del checkout

Torniamo al cliente di apertura, perché racconta il 90% dei casi reali. Situazione: WooCommerce, 1200 ordini al mese, hosting managed di fascia alta, plugin di sicurezza scaduto da otto mesi, nessuna routine di controllo. Lo skimmer iniettava uno script offuscato nel checkout, esfiltrava i dati verso un dominio registrato due settimane prima dell'attacco. Tempo medio di permanenza: quattro settimane. Nessun alert, da nessuna parte.

La pulizia ci ha presi due giorni: rimozione del plugin compromesso (era stato abbandonato dallo sviluppatore, il pattern ricorrente che ho raccontato nell'articolo sui plugin senza patch), rimpiazzo con un'alternativa mantenuta, reset di tutte le credenziali, analisi dei log del WAF per capire l'ingresso. I log c'erano, ed erano inutili: nessuno li leggeva da mesi. Costo totale per il cliente: consulenza, due giorni di fermo parziale, e il conto dell'immagine con i clienti che avevano ricevuto avvisi dalla banca.

La lezione non è «l'hosting è una truffa». La lezione è che il formaggio svizzero va gestito per intero: l'host copre la sua fetta, ma le fette applicative — plugin aggiornati, utenti, file, monitoraggio — sono vostre, o di chi vi fa la manutenzione. Se il vostro provider non comunica con chi fa la manutenzione, avete due fette di formaggio che non si parlano.

Checklist: come scegliere senza fregolerie del marketing

Riassumo in cinque punti operativi quello che vi consiglio di fare la prossima volta che valutate un provider, o rivalutate quello attuale:

• Chiedete patch velocity e virtual patching con numeri e date, non pagine di features.
• Verificate chi custodisce e legge i log, e per quanto tempo.
• Testate un restore in staging prima di firmare: chi si rifiuta vi sta dicendo qualcosa.
• Accoppiate sempre hosting e manutenzione applicativa: sono due contratti diversi, non un pacchetto.
• Eseguite il test WP-CLI dei 15 minuti ogni mese, con una routine che non dipenda dalla memoria di nessuno. Oppure delegate l'intera routine a chi la fa per mestiere: ecco perché esiste l'assistenza WordPress.

Se volete partire da una routine già pronta, la routine mensile che uso con i miei clienti copre proprio questi controlli in automatico, con report. E se il vostro caso è più complesso — multisite, checkout, dati sanitari — qui trovate il servizio di assistenza WordPress con cui lavoriamo a livello di infrastruttura e applicazione insieme, che è l'unico modo in cui questo problema si risolve davvero.

Una nota finale sul costo. Il cliente di apertura ha sostituito 480€ di hosting «sicuro» con 300€ di hosting normale più 600€ l'anno di manutenzione applicativa reale. Spende di più in assoluto e meno in pericolo. Questa è la matematica che il marketing della sicurezza non vi mostrerà mai.

Riferimenti utili

• WP Tavern #227: Maciek Palmowski, does secure hosting deliver?
• Patchstack: ricerche e report sulla sicurezza WordPress
• Hosting WordPress: uptime, E-E-A-T e credibilità del sito
• Manutenzione WordPress: la routine mensile che evita i disastri
• Sito WordPress hackerato: ripristino e sicurezza
• Assistenza WordPress: interventi e piani