Una vulnerabilità critica nel plugin Avada Builder, con CVSS 9.1 e tracciata come CVE-2026-8713, ha messo a rischio circa un milione di siti WordPress fino al rilascio della versione 3.15.4 il 2 giugno 2026. Il difetto, segnalato dai ricercatori di Wordfence, permette a un attaccante non autenticato di cancellare file arbitrari sul server fino a causare il takeover completo del sito.
CVE-2026-8713: il difetto nel codice di Avada Builder
La falla si annida nella funzione maybe_delete_files() all’interno della routine di privacy cleanup del modulo Form Builder di Avada (Fusion) Builder. Il plugin gestisce in automatico la cancellazione delle entry dei form dopo un periodo configurabile, per rispettare i requisiti di minimizzazione dei dati personali. Tuttavia la funzione non eseguiva alcuna validazione del path tramite realpath() né verificava il contenimento all’interno della cartella uploads, lasciando un buco di path traversal sfruttabile da qualunque utente non autenticato.
In pratica un attaccante può inviare un payload di path traversal verso l’handler wp_ajax_nopriv_fusion_form_submit_ajax, controllando i campi fusion_privacy_expiration_interval e privacy_expiration_action per forzare l’azione “delete” e l’esecuzione immediata. La entry malevola viene processata dalla routine Fusion_Form_DB_Privacy in fase di shutdown del processo PHP, senza richiedere alcuna interazione da parte di un amministratore. Il file indicato nel payload viene cancellato dal filesystem con i privilegi dell’utente web, aprendo la strada a scenari di compromissione gravi.
L’impatto: dalla cancellazione file alla compromissione totale
La cancellazione arbitraria di file su WordPress non è un problema “estetico”: è una catena di exploit che può portare al controllo completo del sito. Eliminando il file wp-config.php, ad esempio, si forza WordPress a entrare in modalità di setup iniziale: a quel punto un attaccante con tempismo sufficiente può connettere l’installazione a un proprio database remoto, creare un utente amministratore e impossessarsi del sito. Allo stesso modo è possibile cancellare file di sicurezza, plugin di hardening, file di firma di temi premium, log di audit e qualunque altro asset del server raggiungibile dall’utente web.
Lo scenario peggiore è quello di un piccolo e-commerce di Torino con catalogo costruito su un tema basato su Avada e backup non testati: una richiesta HTTP confezionata ad arte può cancellare i file core del sito in pochi secondi, bloccare l’attività e lasciare l’amministratore davanti a una “white screen of death” in piena giornata di vendite. Per chi gestisce decine di siti clienti sotto la stessa infrastruttura, la velocità di propagazione di un attacco di massa è il problema reale: il bot scansiona, identifica il plugin, lancia il payload e passa al sito successivo, senza alcuna interazione umana. Wordfence ha confermato i requisiti minimi di sfruttamento: basta che sul sito sia pubblicato un form Avada configurato per salvare le entry a database.
Timeline della scoperta e disclosure
Il processo di responsible disclosure si è svolto in modo rapido e coordinato. Il 13 maggio 2026 il ricercatore di sicurezza ha segnalato la vulnerabilità a Wordfence attraverso il programma Bug Bounty. Il 15 maggio Wordfence ha validato la prova di concetto e ha inoltrato il report al team di ThemeFusion, lo sviluppatore di Avada. Il 19 maggio il vendor ha implementato la patch nel ramo di sviluppo del plugin. Il 2 giugno 2026 è stata rilasciata pubblicamente la versione 3.15.4, che risolve definitivamente il problema introducendo la validazione del path tramite realpath() e l’enforcement del contenimento nella cartella uploads.
I clienti Wordfence Premium, Care e Response hanno ricevuto la regola firewall il 13 maggio 2026, gli utenti della versione gratuita del firewall il 12 giugno 2026. Questo gap di un mese è il classico finestra di esposizione che fa la differenza tra un’agenzia che paga la sicurezza come servizio e una che si affida solo a strumenti gratuiti. Le installazioni che non hanno ancora aggiornato il plugin restano vulnerabili e in alcune configurazioni il payload è ancora oggi nelle scansioni di massa registrate dai sistemi di monitoraggio. Gli analisti raccomandano di considerare ogni sito non aggiornato come potenzialmente compromesso e di procedere a una verifica di integrità completa.
Cosa controllare oggi sui siti che gestisci
La verifica deve essere puntuale e non limitarsi al solo aggiornamento del plugin. Avada è venduto come tema premium e include diversi moduli (Fusion Builder, Avada Core, Fusion Core), distribuiti talvolta come dipendenze nascoste o come bundle. È necessario controllare la versione installata in WP Admin > Plugins, ma anche verificare la presenza di copie obsolete in wp-content/upgrade, eventuali installazioni multisito, ambienti di staging dimenticati e backup automatici che potrebbero contenere ancora la versione vulnerabile.
Va anche analizzato il log del web server per cercare richieste verso admin-ajax.php con action fusion_form_submit_ajax contenenti caratteri sospetti come ../ o riferimenti a file di sistema. Se vengono trovati pattern compatibili con tentativi di exploit, è opportuno isolare il sito, eseguire una verifica di integrità dei file core di WordPress, ripristinare un backup pulito antecedente alla data sospetta e procedere con la rotazione delle credenziali. Per le agenzie che ospitano siti clienti su infrastrutture condivise, vale la pena lanciare uno script di inventario massivo che identifichi tutte le installazioni di Avada Builder e ne confronti la versione con la 3.15.4 minima richiesta.
Cosa significa per la tua agenzia o PMI
La vulnerabilità di Avada Builder è un caso di scuola che insegna come anche un plugin commerciale, premium e largamente diffuso possa contenere bug critici. Per chi gestisce siti WordPress di terzi, la velocità di reazione fa la differenza tra un incidente contenuto e una crisi conclamata. Cinque azioni concrete da mettere a calendario oggi:
- Aggiornare immediatamente Avada Builder alla versione 3.15.4 o successiva su tutti i siti gestiti, inclusi ambienti di staging e installazioni di backup attive.
- Eseguire una scansione di integrità dei file con un tool come Wordfence, MalCare o Patchstack, confrontando l’output con uno snapshot pulito noto.
- Verificare i log del web server delle ultime 6 settimane alla ricerca di richieste sospette verso
fusion_form_submit_ajaxcon caratteri di path traversal. - Implementare un processo di patch management con SLA dichiarato (ad esempio 48 ore dalla pubblicazione di CVE critici) e comunicato ai clienti come parte del contratto.
- Attivare un firewall applicativo (Wordfence Premium, Patchstack, BBQ Pro o equivalente) che riceva regole virtuali prima del rilascio della patch ufficiale.
Per un’agenzia con una manciata di siti su Avada, l’aggiornamento è questione di un pomeriggio. Per chi gestisce decine o centinaia di installazioni, è il momento di valutare un sistema di gestione centralizzata (MainWP, ManageWP, InfiniteWP o pannelli proprietari) che permetta di lanciare aggiornamenti di massa e ricevere report di stato sulla flotta. La gestione manuale, sito per sito, non è più sostenibile quando le finestre di esposizione si misurano in ore.
