WordPress espone un milione di siti con falle Avada Builder e FunnelKit

WordPress affronta una nuova ondata di vulnerabilità critiche con Avada Builder e FunnelKit, due plugin molto diffusi che espongono siti, negozi WooCommerce e dati sensibili a furti di carte di credito, credenziali e file interni. Avada Builder mette a rischio oltre un milione di installazioni con lettura arbitraria di file e SQL injection, mentre FunnelKit Funnel Builder viene sfruttato attivamente per iniettare skimmer di pagamento su oltre 40.000 negozi WooCommerce. Gli attaccanti possono accedere a file come wp-config.php, sottrarre password hash, chiavi crittografiche e dati di pagamento, oppure inserire codice JavaScript malevolo nelle pagine di checkout. Gli sviluppatori hanno già rilasciato patch urgenti: Avada Builder 3.15.3 corregge entrambe le vulnerabilità, mentre FunnelKit 3.15.0.3 blocca l’iniezione di script tramite endpoint pubblico. Le ricerche di Sansec e Wordfence indicano exploit reali e un rischio concreto per siti e-commerce già esposti. Gli amministratori devono aggiornare subito i plugin, controllare script sconosciuti nelle impostazioni di checkout e verificare eventuali compromissioni pregresse. La vicenda conferma quanto l’ecosistema WordPress dipenda dalla sicurezza dei plugin: ogni estensione amplia le funzionalità, ma può anche diventare un vettore d’attacco se permessi, input e query non vengono validati correttamente.

FunnelKit espone WooCommerce al furto di carte di credito

FunnelKit Funnel Builder contiene una vulnerabilità critica in un endpoint pubblico di checkout che non verifica correttamente i permessi dell’utente. Un attaccante non autenticato può chiamare un metodo interno e scrivere dati arbitrari nel campo External Scripts delle impostazioni globali del plugin. Questo campo viene poi renderizzato come JavaScript su ogni pagina di checkout, trasformando una funzione legittima di marketing e tracciamento in un canale di infezione. Gli aggressori sfruttano il bug per inserire uno script mascherato da Google Tag Manager o Google Analytics, rendendo l’iniezione più difficile da notare a un controllo superficiale. Il codice decodifica un URL Base64 e carica un payload esterno che apre una connessione WebSocket verso un server di comando e controllo. Da lì viene consegnato uno skimmer personalizzato per il negozio compromesso. Il malware intercetta numeri di carta, CVV, indirizzi di fatturazione e altri dati inseriti durante il pagamento. Il bug colpisce tutte le versioni precedenti a FunnelKit 3.15.0.3, rilasciata il 14 maggio 2026 con capability check e whitelist dei metodi sicuri.

Gli skimmer sfruttano script finti di analytics nel checkout

L’attacco contro FunnelKit risulta particolarmente pericoloso perché si confonde con il normale funzionamento di un negozio online. L’attaccante invia una richiesta all’endpoint pubblico del plugin e, in assenza di controlli di autorizzazione, salva il codice malevolo nelle impostazioni globali. Lo script appare legittimo perché imita tag di analytics già comuni nei siti e-commerce. Al caricamento della pagina di checkout, il codice aggiunge dinamicamente un elemento script al body e recupera il payload esterno. Sansec ha osservato infrastrutture come analytics-reports[.]com/wss/jquery-lib.js e connessioni wss://protect-wss[.]com/ws, usate per distribuire skimmer su misura. Il server di comando e controllo adatta il codice alla struttura del form del negozio e cattura i dati di pagamento prima che l’utente completi l’acquisto. La tecnica consente di bypassare controlli manuali poco approfonditi perché il codice sembra parte dei normali strumenti di misurazione. Gli utenti non vedono anomalie evidenti durante il checkout, mentre i dati vengono inviati all’infrastruttura dell’attaccante. Proprio questa silenziosità rende indispensabile una scansione dedicata dopo l’aggiornamento.

Avada Builder permette lettura di file e SQL injection

Avada Builder presenta due vulnerabilità distinte che mettono a rischio circa un milione di siti WordPress. La prima falla, identificata come CVE-2026-4782, consente lettura arbitraria di file tramite il rendering degli shortcode e il parametro custom_svg. Un utente autenticato con ruolo subscriber può leggere file sensibili sul server, incluso wp-config.php, che contiene credenziali del database, chiavi crittografiche e configurazioni fondamentali dell’installazione WordPress. La seconda vulnerabilità, CVE-2026-4798, è una SQL injection time-based blind tramite il parametro product_order, inserito direttamente nella clausola ORDER BY senza sanitizzazione adeguata. Questa falla può essere sfruttata anche da utenti non autenticati, ma richiede una condizione specifica: WooCommerce deve essere stato abilitato e poi disabilitato lasciando le tabelle nel database. Insieme, le due vulnerabilità espongono credenziali, hash di password e dati interni, aprendo la strada a takeover completi. La versione Avada Builder 3.15.2 aveva corretto solo parzialmente la lettura di file il 13 aprile, mentre Avada Builder 3.15.3 del 12 maggio risolve completamente entrambe le issue.

Le falle di Avada Builder espongono wp-config.php e database

L’impatto concreto delle vulnerabilità in Avada Builder riguarda soprattutto il furto di credenziali e il controllo del sito. La lettura arbitraria di file consente di estrarre wp-config.php, uno dei file più sensibili in un’installazione WordPress. Al suo interno sono presenti credenziali del database, chiavi di autenticazione, salt crittografici e informazioni utili per manipolare sessioni o accedere a componenti interni. Su siti che consentono registrazione utenti, ottenere un account subscriber può essere banale e sufficiente per avviare l’attacco. La SQL injection amplia ulteriormente la superficie di rischio perché permette di estrarre hash di password dal database, anche senza autenticazione nelle configurazioni vulnerabili. Un aggressore può combinare le informazioni ottenute per scalare privilegi, compromettere account amministrativi, installare backdoor, modificare contenuti o sottrarre dati dei clienti. Wordfence evidenzia la gravità del problema proprio per la combinazione tra facilità di sfruttamento e ampiezza dell’installato. Quando un page builder così diffuso contiene bug in funzioni di rendering e query, il rischio non resta teorico ma diventa immediatamente operativo per migliaia di siti.

Le patch urgenti chiudono FunnelKit e Avada Builder

Gli sviluppatori hanno già pubblicato correzioni urgenti per entrambe le famiglie di vulnerabilità. FunnelKit 3.15.0.3, rilasciato il 14 maggio 2026, aggiunge controlli di capacità e una whitelist dei metodi sicuri, bloccando la possibilità di scrivere script arbitrari nelle impostazioni globali del checkout. Gli amministratori devono aggiornare direttamente dalla dashboard WordPress e controllare subito la sezione Checkout > External Scripts per rimuovere eventuali script sconosciuti o sospetti. Avada Builder 3.15.3, rilasciato il 12 maggio, corregge completamente la lettura arbitraria di file e la SQL injection, superando la patch parziale contenuta nella versione 3.15.2. Gli aggiornamenti possono essere applicati dal repository, dal pannello di gestione o dai canali ufficiali del tema/plugin. Prima dell’update resta prudente eseguire un backup completo, ma il rinvio dell’installazione espone a exploit già documentati. Dopo l’aggiornamento, gli amministratori dovrebbero svuotare cache, controllare log web, verificare utenti sconosciuti, cercare file PHP anomali e monitorare modifiche recenti ai template. Per e-commerce compromessi, una semplice patch potrebbe non bastare: serve anche una bonifica del codice iniettato.

Sansec e Wordfence confermano exploit attivi su larga scala

Le ricerche di Sansec e Wordfence confermano che queste vulnerabilità non rappresentano soltanto problemi teorici di codice. Nel caso di FunnelKit, Sansec osserva exploit attivi contro negozi WooCommerce con skimmer già iniettati nelle pagine di pagamento. Questo significa che alcuni siti potrebbero aver già esposto dati di carte e informazioni personali dei clienti prima dell’applicazione della patch. Nel caso di Avada Builder, Wordfence segnala l’impatto su oltre un milione di installazioni e descrive una combinazione di bug capace di portare al furto di credenziali e takeover del sito. La diversa natura delle falle rende il quadro ancora più serio: FunnelKit colpisce direttamente il flusso di pagamento, mentre Avada compromette file e database. Gli amministratori devono quindi distinguere tra aggiornamento preventivo e risposta a incidente. Un sito che ha usato versioni vulnerabili potrebbe richiedere scansione malware, rotazione delle chiavi WordPress, cambio delle password amministrative, verifica degli utenti e controllo dei pagamenti sospetti. Per gli e-commerce, andrebbero valutate anche notifiche ai provider di pagamento e revisione degli ordini recenti.

WordPress resta esposto quando i plugin non validano permessi e input

Il caso Avada Builder e FunnelKit mostra perché l’ecosistema WordPress rimanga un bersaglio privilegiato per attacchi di massa. I plugin estendono rapidamente funzionalità essenziali come page building, checkout, marketing automation e tracking, ma introducono anche endpoint pubblici, shortcode, form, query dinamiche e campi scriptabili. Se mancano capability check, sanitizzazione degli input e query preparate, una funzionalità utile può diventare un canale di compromissione. Avada Builder è particolarmente appetibile perché installato su scala enorme, mentre FunnelKit interessa direttamente negozi WooCommerce che trattano pagamenti reali. Gli attaccanti scelgono questi bersagli perché producono dati di alto valore con costi operativi bassi. Una singola vulnerabilità in un plugin popolare può diventare rapidamente una campagna globale. La risposta della community dimostra comunque una capacità di reazione importante: ricercatori indipendenti individuano gli exploit, vendor rilasciano patch e firewall applicativi aggiornano le regole. Il punto debole resta la finestra tra disclosure, aggiornamento e bonifica, soprattutto su siti gestiti da piccole attività senza presidio tecnico continuo.

Gli amministratori devono aggiornare e verificare compromissioni

Gli amministratori WordPress devono installare immediatamente FunnelKit 3.15.0.3 e Avada Builder 3.15.3 o versioni successive. Dopo l’aggiornamento conviene controllare la sezione External Scripts di FunnelKit, verificare eventuali JavaScript sconosciuti, cercare domini sospetti e analizzare il codice delle pagine checkout. Per i siti con Avada Builder, è necessario verificare utenti registrati anomali, accessi subscriber sospetti, richieste a shortcode insolite e query lente o ripetute nei log. La rotazione delle password amministrative e delle credenziali del database diventa raccomandata se esiste anche solo il sospetto di accesso a wp-config.php. Le chiavi e i salt WordPress dovrebbero essere rigenerati per invalidare sessioni potenzialmente compromesse. Nei negozi WooCommerce è opportuno controllare transazioni recenti, segnalazioni dei clienti e integrazioni con gateway di pagamento. Strumenti come Wordfence Security, scanner malware e soluzioni specializzate come eComscan possono aiutare a individuare skimmer e backdoor. La protezione futura richiede aggiornamenti automatici dove possibile, backup verificati, principio del minimo privilegio e revisione periodica dei plugin installati. In un ecosistema così esteso, sicurezza e manutenzione non possono più essere attività occasionali.

Le vulnerabilità rafforzano la lezione per la community WordPress

Le falle di FunnelKit e Avada Builder offrono una lezione chiara alla community WordPress. La vulnerabilità FunnelKit nasce da un endpoint pubblico senza controlli adeguati e colpisce direttamente i flussi di pagamento, con impatto immediato su carte di credito e dati dei clienti. Le vulnerabilità Avada Builder derivano invece da input non validati in funzioni di rendering e query, esponendo file sensibili e database. In entrambi i casi il problema centrale riguarda l’assenza o l’insufficienza di controlli su permessi, sanitizzazione e output. Gli sviluppatori devono adottare capability check rigorosi, prepared statements, escaping coerente e audit continui sulle funzioni esposte. Gli utenti finali devono comprendere che plugin molto diffusi non sono automaticamente sicuri e che ogni componente aggiunto aumenta la superficie d’attacco. Le aziende che gestiscono e-commerce dovrebbero trattare la sicurezza WordPress come parte della continuità operativa, non come una manutenzione secondaria. La risposta rapida con patch è positiva, ma il vero elemento decisivo resta la velocità con cui amministratori e agenzie applicano gli aggiornamenti e verificano eventuali compromissioni già avvenute.