Il primo pensiero che ho fatto leggendo l'advisory è stato per un cliente preciso: un'agenzia che gestisce un sito con Avada 7.12 installato nel 2023 e aggiornato, a direzioni alterne, solo a metà. Per fortuna in staging, e per fortuna con Fusion Builder aggiornato nel mentre. Ma la domanda che quel caso mi ha imposto di rispondere è quella di questa guida: se "premium" non significa "sicuro", cosa significa? E come si fa l'audit dei temi — premium, nulled, dimenticati — prima che un advisory lo dica a te? Ed è una domanda che mi fa spesso chi gestisce il sito da solo: in quel caso la risposta breve è che l'audit si può fare in una mezza giornata, e che da lì in poi conta la routine — quella che un servizio di assistenza WordPress applica ogni settimana invece che ogni incidente.

Cosa ha permesso la RCE su Avada

Vediamo la meccanica, perché spiega perché i temi premium sono una superficie particolare. La vulnerabilità è un arbitrary file write: una funzione del tema permetteva di scrivere sul server file con contenuto controllato dall'attaccante, senza autenticazione. Da lì il passo è corto e classico: si scrive un file con estensione .php, lo si raggiunge via web, e il server lo esegue. Esecuzione di codice remoto, accesso totale: database, credenziali, mailing list, pagamenti, tutto.

Il dettaglio che allarga il problema è il plugin bundled. Avada viene fornito con Fusion Builder, il suo page builder, che gira come plugin separato. La vulnerabilità colpiva il tema fino alla 7.16 inclusa quando Fusion Builder, attivo, fosse alla 3.16 o precedente. Questo schema — tema più plugin companion che viaggiano insieme — è lo standard dei temi premium moderni, e raddoppia la superficie: due componenti da tenere aggiornati in sincrono, dove un aggiornamento parziale può lasciare aperto il buco del compagno.

Chi ha un Avada aggiornato dopo il fix è a posto. Il punto di questa guida è l'altro: quanti proprietari di siti premium sanno di dover aggiornare due cose, non una? E quanti lo fanno con la disciplina di chi gestisce plugin di sicurezza?

Premium non è sinonimo di sicuro: i numeri della settimana

La lezione di Avada arriva insieme ad altri quattro casi, nella stessa finestra di poche settimane. Il plugin WPMU DEV Dashboard con un bypass di autenticazione sfruttabile quando il Single Sign-On dell'Hub è attivo. TranslatePress che espone l'URL di reset password dell'amministratore, con 400.000 siti potenzialmente colpiti. Pods, 100.000 siti, con escalation di privilegi verso amministratore. GiveWP con object injection PHP trasformabile in esecuzione remota, CVSS 10.0. E ai margini della finestra, la SQLi su All-in-One WP Migration, il plugin vulnerabile che ha esposto 3,25 milioni di siti.

Guardali insieme e il pattern salta agli occhi: non sono prodotti abbandonati o arrangiati in un weekend. Sono componenti diffusi, curati, a pagamento o con business model serio, sotto il foglio di calcolo di ricercatori che li analizzano con più attenzione che mai. Il 1° settembre WordPress.org ha aggiornato le linee guida del proprio Vulnerability Disclosure Program nella stessa direzione: meno report marginali, più attenzione ai difetti sfruttabili senza autenticazione o da utenti poco privilegiati. Il risultato è che le vulnerabilità emergono più velocemente di un tempo passato — ed è una buona notizia, non una cattiva — ma significa anche che il tuo tema premium sarà testato, prima o poi, da qualcuno che cerca di romperlo per mestiere.

Temi premium, temi nulled, temi dimenticati

Nel lavoro di audit trovo tre profili di tema, con tre rischi diversi e spesso confusi.

Il premium aggiornato a metà

Il caso più frequente e più subdolo: il tema è stato comprato legittimamente, ma gli aggiornamenti sono seguiti a sprazzi, spesso fermi quando la licenza scade. Avada, come molti premium, richiede rinnovo licenza per aggiornamenti e supporto; molti decidono che non serve, e il tema resta sulla versione acquistata. Il risultato è un componente che ha le vulnerabilità di tutti gli anni che non ha attraversato. Nel caso della CVE-2026-18431: se il tuo Fusion Builder è rimasto alla 3.16 o precedente, la RCE ti riguarda, tema acquistato o meno. È il caso più comune che incontro nel supporto WordPress gestito: non una negligenza vera, una scadenza passata in silenzio che nessuno ha trasformato in azione.

Il nulled scaricato da un forum

Quello che va detto senza sconti: i temi nulled — copie dei premium con licenza aggirata — sono un problema di sicurezza prima che etico. Chi distribuisce il nulled ha tutto l'interesse e nessun vincolo a infilare codice dentro il pacchetto. Ho visto siti con backdoor preinstallate nel tema nulled, non come conseguenza della vulnerabilità ma come parte del pacchetto scaricato. Il quadro dei plugin piratati e di dubbia provenienza si applica identicamente ai temi: il risparmio di sessanta dollari si misura in giorni di pulizia.

Il dimenticatoio attivo

Il terzo profilo è il tema installato e attivo ma non più guardato da nessuno: il sito funziona, nessuno tocca nulla, il tema "non dà problemi". È il profilo che più si lega al PHP legacy di cui abbiamo parlato in un'altra guida: un tema vecchio che gira su un runtime vecchio, con entrambi senza fix. Il tema dimenticato non ha la drammaticità del nulled, ma l'effetto nel tempo è lo stesso: una vecchia versione di codice esposta a vulnerabilità che vengono scoperte e sfruttate mentre lui dorme.

L'audit del tema in 6 passi

Veniamo alla pratica: come controllare il tuo tema in mezza giornata di lavoro, ordinato come lo eseguirei io.

Primo: inventario. Che tema è, che versione, da quanto è installato, chi lo ha messo. Da terminale, due comandi bastano:

wp theme list --allow-root
wp plugin list --status=active --field=name --allow-root

Secondo: changelog del fornitore. Confronta la tua versione con l'ultima rilasciata: se sei indietro di due o tre release minori va bene, se sei indietro di dodici mesi hai trovato il primo problema. Cerca nelle note di rilascio le parole "security" e "fix": ogni corrispondenza è una finestra rimasta aperta.

Terzo: componenti bundled. Lista dei plugin companion che il tema installato o richiede (per Avada: Fusion Builder, Fusion Core). Verifica le versioni separatamente: l'aggiornamento del tema non sempre trascina quello del companion.

Quarto: demo content e import non usati. Molti temi premium importano template, slider e pagine demo con funzioni potenti che restano attive anche dopo. Se non usi l'importer, disattivalo; se hai importato demo per provarle e poi non le hai pulite, le hai lasciate in produzione con i loro shortcode e i loro endpoint.

Quinto: test in staging. Ogni aggiornamento del tema — soprattutto il salto di major — va provato in staging: template che cambiano, classi CSS rinominate, funzioni deprecate. È la stessa disciplina delle procedure per aggiornare WordPress senza rompere il sito: mai in produzione senza prova.

Sesto: decisione scritta. Alla fine dell'audit scrivi in due righe la decisione: aggiornato a X in data Y, oppure sostituzione prevista entro la data Z. Un audit senza decisione documentata si ripete all'infinito.

Se la mezza giornata non ce la fai, è esattamente il tipo di controllo che entra nella routine di manutenzione WordPress del nostro servizio di assistenza: non è l'audit straordinario, è la verifica periodica che evita l'audit straordinario. Ed è anche il modo più economico di stare al passo: aggiornare un tema ogni mese costa una frazione di ciò che costa recuperare dodici mesi di ritardi con una RCE alle porte.

Quando conviene cambiare tema

La domanda onesta che arriva dopo un audit: conviene aggiornare, o cambiare tema? La risposta la danno tre fattori, non il gusto.

Il primo fattore è la distanza: se sei indietro di una o due release, aggiorna; se il tuo tema è un ramo morto — fornitore sparito, ultima release di due anni fa — ogni giorno di attesa aumenta il rischio senza più controvalore. Il secondo è l'architettura: i page builder classici portano con sé shortcode e dati proprietari nel database, e questo rende la sostituzione un progetto, non un'installazione; i block theme nativi legano il design ai blocchi core e rendono la migrazione più pulita (per chi parte da zero, la guida alla creazione di un tema WordPress mostra bene la struttura a blocchi) — sulla direzione del mercato abbiamo raccontato cosa cambia con i temi a blocchi e l'AI. Il terzo è l'ecosistema attorno: se il tuo tema richiede plugin companion con storie di sicurezza instabile, stai pagando un affitto invisibile.

Il calcolo che propongo ai clienti è in giorni: aggiornamento con test in staging, mezza giornata; sostituzione completa con rebuild dei template, da tre giorni a due settimane secondo complessità; incident di sicurezza con ripristino e pulizia, da una settimana in su, con clienti che non ti chiamano mentre sei offline. La sostituzione raramente vince sul breve periodo. L'aggiornamento trascurato perde quasi sempre sul lungo.

Un'ultima nota pratica, che viene dalla esperienza diretta: chi cambia tema per motivi di sicurezza quasi sempre scopre benefici che non aveva messo a conto. Template più puliti, meno shortcode orfani nel database, meno CSS inutilizzato, e spesso una velocità migliore senza aver toccato la cache. Il sito dell'agenzia che segue la CVE di Avada da vicino ha fatto l'audit in una mattinata: tema aggiornato, Fusion Builder allineato, demo importer disattivato, e una decisione scritta — next major salto solo dopo prova in staging. Nessuna drammaticità: la sicurezza dei temi premium è diventata questo, una routine che si può pianificare invece di un incendio da spegnere.

E il ciclo si chiude dove è iniziato: con la ricerca. Wordfence e Patchstack pubblicano advisory dettagliate proprio perché la comunità le usi, e chi le legge con un piano in mano si trova nelle condizioni del mio cliente — decisione presa, porta chiusa, sostituzione pianificata — invece che in quelle dei possessori di siti che scoprono la vulnerabilità dal diario di un attacco. Se la tua posizione attuale è "tema premium, licenza in regola, aggiornamenti saltuari", la sequenza che ti serve è tutta in questa pagina: audit dei sei passi, decisione scritta, e — se i tempi tuoi non bastano — la delega della routine a chi la fa per mestiere, che è in fondo il modello con cui funziona anche l'assistenza WordPress che proponiamo: non servire quando brucia, ma evitare che bruci.

Riferimenti utili

• Wordfence: la RCE a 6 passi sul tema Avada
• The Hacker News: cinque vulnerabilità critiche in plugin e temi WordPress
• WordPress.org: aggiornamenti al Vulnerability Disclosure Program
• Plugin WordPress vulnerabile: 3,25 milioni di siti esposti
• WordPress hackerato: guida al ripristino e alla sicurezza