In pochi giorni Wordfence e Patchstack hanno pubblicato cinque vulnerabilità critiche che riguardano plugin e temi WordPress con una diffusione enorme: WPMU DEV Dashboard, Avada, TranslatePress, Pods e GiveWP. Quattro sono valutate CVSS 9.8, una raggiunge il massimo, 10.0. In tutti i casi l'esito è lo stesso: presa di controllo del sito, spesso senza autenticazione e senza alcuna interazione della vittima.

Non è una notizia per addetti ai lavori. In Italia WordPress è l'infrastruttura di fatto dei siti di PMI, studi professionali, associazioni, enti del terzo settore e strutture ricettive. Ed è quasi sempre il componente per cui nessuno, dentro l'organizzazione, ha formalmente la responsabilità degli aggiornamenti.

Le cinque falle

CVE-2026-82222 (CVSS 10.0) — GiveWP. Vulnerabilità di PHP object injection che porta all'esecuzione di comandi arbitrari sul server. Riguarda tutte le versioni fino alla 4.16.7.1 compresa e si innesca su un sito che abbia almeno un modulo di donazione pubblicato e un gateway di pagamento attivo — cioè su qualsiasi installazione realmente in uso. L'analisi di Patchstack descrive la catena: un helper di "safe unserialize" che non rimuove davvero gli oggetti, un flusso di donazione che gli passa dati controllati dall'attaccante e una gadget chain presente in librerie che GiveWP distribuisce. La radice del problema, scrive Patchstack, è ricorrente: fidarsi di un sanitizzatore di serializzazione che non sanitizza, deserializzare dati riletti dal database come se fossero attendibili e spedire in produzione librerie pensate per lo sviluppo.

CVE-2026-18431 (CVSS 9.8) — tema Avada. Scrittura arbitraria di file che si converte in esecuzione di codice PHP e quindi in compromissione completa del sito. Colpisce Avada fino alla 7.16 compresa quando è attivo il plugin Fusion Builder fino alla 3.16. Wordfence la descrive come una catena di sei passaggi, sfruttabile senza autenticazione e senza interazione dell'utente: uno zero-click. ThemeFusion ha rilasciato le correzioni il 25 agosto 2026: Avada 7.16.1 e Fusion Builder 3.16.1. Avada è uno dei temi commerciali più venduti di sempre, con oltre un milione di licenze.

CVE-2026-76581 (CVSS 9.8) — WPMU DEV Dashboard. Bypass dell'autenticazione che consente a un attaccante non autenticato di ottenere privilegi di amministratore. Interessa tutte le versioni fino alla 5.0.1 sui siti collegati a WPMU DEV con Hub Single Sign-On attivo e mappato su un amministratore. La causa tecnica è un'incoerenza nel modo in cui il plugin costruisce e verifica le firme HMAC-SHA-256 nel flusso SSO: l'endpoint AJAX non autenticato del primo stadio si comporta da signing oracle, produce cioè una firma valida che può essere riutilizzata in un contesto logico diverso. L'attacco non richiede di conoscere la API key del sito. Il plugin conta circa 350.000 installazioni attive; la versione 5.0.2 è del 24 agosto 2026.

CVE-2026-19632 (CVSS 9.8) — TranslatePress. Esposizione di informazioni sensibili che permette a un attaccante non autenticato di estrarre l'URL grezzo di reset della password di un amministratore, chiave di reset in chiaro e parametri di login compresi, con conseguente presa di controllo dell'account. Riguarda le versioni fino alla 3.3.1 compresa, ma solo quando è attivo il salvataggio automatico delle stringhe e la lingua del profilo dell'amministratore è impostata su una lingua secondaria pubblicata. Wordfence stima 400.000 siti interessati.

CVE-2026-19598 (CVSS 9.8) — Pods. Escalation di privilegi che consente a un attaccante non autenticato di diventare amministratore o di sovrascrivere la password di qualsiasi utente, incluso il proprietario del sito. Colpisce le versioni fino alla 3.3.9 compresa, su circa 100.000 siti.

Cosa significa per le aziende e gli enti italiani

Il rischio non è "il sito va giù". È l'esatto contrario: un sito compromesso che continua a funzionare perfettamente vale molto di più. Serve a ospitare pagine di phishing sotto un dominio con buona reputazione, a distribuire malware ai propri stessi visitatori, a inviare spam usando l'IP e la reputazione del mittente. La compromissione tipica di WordPress in Italia non viene scoperta dall'IT ma dal commerciale, quando i clienti smettono di ricevere le email o il browser mostra un avviso rosso.

GiveWP tocca un settore particolarmente esposto. Il plugin serve la raccolta fondi, quindi il suo bacino sono ONLUS, enti del terzo settore, associazioni, parrocchie, comitati e fondazioni: organizzazioni che trattano dati di donatori (nome, email, importo, spesso codice fiscale per la detrazione) e che quasi mai dispongono di un presidio IT interno. Il modulo che permette lo sfruttamento non è un'opzione esotica: è la ragione stessa per cui il plugin è installato.

Avada è il caso più insidioso per il mercato italiano. È un tema comprato una volta, usato dalle agenzie web per costruire il sito, consegnato al cliente e poi dimenticato. Chi lo ha acquistato dieci anni fa spesso non ha più una licenza attiva e quindi non riceve gli aggiornamenti automatici. Il risultato è un parco di installazioni con un difetto sfruttabile da chiunque, senza click, e senza nessuno che stia guardando. È qui che si annida la maggior parte del rischio reale.

TranslatePress segue la mappa dell'export. Il multilingua in Italia è tipico dei siti di aziende che vendono all'estero, di strutture ricettive e di operatori turistici. Vale la pena notare che la falla si attiva su una configurazione specifica, non su tutte le installazioni: chi verifica prima di correre riduce l'urgenza e organizza meglio il lavoro.

C'è infine un filo che lega questa notizia alle campagne di social engineering delle ultime settimane. Le catene di attacco che partono da un finto CAPTCHA sfruttano siti legittimi compromessi come punto di partenza. Un sito WordPress aziendale con un plugin vulnerabile non è quindi solo un problema di chi lo possiede: diventa lo strumento con cui vengono attaccati i propri clienti e fornitori. È la ragione per cui la manutenzione di un sito istituzionale, per quanto marginale sembri, è a tutti gli effetti una misura di sicurezza verso terzi.

Il quadro normativo

L'art. 32 del GDPR impone misure tecniche e organizzative adeguate al rischio. Un CMS pubblico che tratta dati personali — un modulo contatti, una newsletter, un'area riservata, una donazione — e che gira su un plugin con una falla nota, corretta e non applicata è, in caso di contestazione, una posizione molto difficile da difendere: la vulnerabilità era pubblica, la patch esisteva, non è stata installata.

Se il sito viene compromesso e i dati personali risultano accessibili, scatta l'obbligo di notifica al Garante entro 72 ore (art. 33) e, quando il rischio per gli interessati è elevato — è il caso di credenziali o dati di pagamento — anche la comunicazione agli interessati (art. 34).

Per i soggetti in perimetro NIS2, questi cinque avvisi rientrano nel dominio della gestione delle vulnerabilità e, se il sito è realizzato o mantenuto da un'agenzia esterna, in quello della sicurezza della catena di fornitura. La domanda pratica da porsi è semplice: nel contratto con chi ha fatto il sito, chi applica gli aggiornamenti e in quanto tempo? Nella maggior parte dei contratti italiani questa clausola non esiste.

Cosa fare subito

  • Fare l'inventario. Elencare temi e plugin installati su ogni sito con le rispettive versioni. Non si può correggere ciò di cui non si conosce l'esistenza, e le installazioni dimenticate sono la norma.
  • Aggiornare i componenti coinvolti: Avada a 7.16.1 e Fusion Builder a 3.16.1, WPMU DEV Dashboard a 5.0.2, e GiveWP, Pods e TranslatePress alla prima versione successiva a quella indicata come vulnerabile dagli sviluppatori.
  • Disattivare l'Hub SSO di WPMU DEV se non viene realmente utilizzato: rimuove il prerequisito dello sfruttamento.
  • Verificare la configurazione di TranslatePress (salvataggio automatico delle stringhe, lingua del profilo amministratore) per capire se si è effettivamente esposti.
  • Cercare tracce di compromissione anche dopo l'aggiornamento: utenti amministratori creati di recente, file PHP comparsi in wp-content/uploads, attività pianificate WordPress anomale, modifiche recenti ai file del tema.
  • Rimuovere plugin e temi inattivi. Il codice disattivato resta sul disco e in molti casi resta raggiungibile.
  • Attivare l'autenticazione a due fattori su tutti gli account amministrativi e ridurre il numero di amministratori.
  • Mettere un WAF davanti al sito come misura di contenimento tra la scoperta di una falla e l'installazione della patch, non come sostituto dell'aggiornamento.
  • Formalizzare la manutenzione: mettere per iscritto chi aggiorna, con quale frequenza e con quale tempo di risposta sulle vulnerabilità critiche. È la misura meno tecnica dell'elenco ed è quella che, in Italia, manca più spesso.