Plugin WordPress vulnerabile: 3,25 milioni di siti esposti

Ieri, 2 settembre 2026, Wordfence ha reso pubblica una di quelle vulnerabilità che non si possono ignorare: CVE-2026-19949, un difetto di SQL injection nel plugin All-in-One WP Migration and Backup che espone a takeover completo oltre 3,25 milioni di siti WordPress. Cinque milioni di installazioni attive, e appena il 35% ha già installato la patch. Il messaggio che ne tiro fuori è scomodo: il plugin che usi per proteggere il sito può diventare la porta d'ingresso dell'attacco.

Ne parlo qui perché All-in-One WP Migration è uno dei plugin di backup più diffusi al mondo, presente in tantissimi pacchetti "preconfigurati" e istallazioni di agenzie. Se lo hai, prenditi dieci minuti adesso: la verifica si fa con tre comandi e ti spiego esattamente come.

Cosa è successo, in due minuti

All-in-One WP Migration serve a esportare, importare e spostare interi siti WordPress: database, media, temi e plugin compressi in un archivio .wpress. Il difetto — una SQL injection di secondo ordine — colpisce tutte le versioni fino alla 7.109 e permette a un attaccante non autenticato di preparare un'esecuzione di codice che scatta quando l'amministratore fa quello che fa più spesso: esportare o ripristinare un backup.

La falla è stata scoperta dal ricercatore Jack Taylor e riportata a metà agosto tramite Wordfence, il ramo cybersecurity di Defiant. La timeline è normale, anzi buona: divulgazione allo sviluppatore ServMask il 15 agosto, patch rilasciata il 20 agosto con la versione 7.110, disclosure pubblica il 2 settembre. Dodici giorni tra segnalazione e fix: rispettabile. Il problema è l'altra parte della timeline — i 3,25 milioni di siti che in undici giorni di patch pubblica non hanno ancora aggiornato.

La catena dell'attacco, passo per passo

Il meccanismo è tecnicamente interessante, e vale la pena capirlo perché ripeterà il teorema: è quello che in gergo si chiama attacco "dormiente".

1. L'attaccante pianta dati truccati nel database del sito tramite trackback — funzione WordPress antica, spesso attiva quando nessuno se lo ricorda
2. I dati restano inerti, innocui: nessun allarme, nessun sintomo
3. Quando l'amministratore esporta o importa il sito, il plugin riscrive il contenuto del database durante la creazione dell'archivio. Ed è lì che un parsing scorretto di backslash e apici escapati fa eseguire i dati piantati come SQL
4. L'SQL iniettato espone la chiave segreta di importazione del plugin (ai1wm_secret_key) tramite un commento pubblico
5. Con quella chiave, l'attaccante importa un archivio .wpress appositamente costruito che contiene codice eseguibile: prende il controllo completo del sito

Nota il verso: non serve che l'attaccante entri nell'admin, non servono credenziali rubate, non serve brute force. Basta che il tuo plugin di backup faccia il suo lavoro — esportare o ripristinare — nel momento sbagliato.

Perché è furba: dorme finché non fai un backup

La parte che secondo me rende questa vulnerabilità didattica è il trigger. Wordfence lo dice chiaramente: l'SQL iniettato non esegue finché non avviene l'operazione di export o import, che per un plugin di backup è un'azione di routine. Un'amministratore che pianifica migrazioni stagionali, staging periodici o riorganizzazioni del sito può tenere il "detonatore" nel database per mesi, senza alcun segnale.

E c'è un dettaglio in più: anche una versione vulnerabile disattivata è un rischio minore ma reale — basta che venga riattivata, magari da un altro plugin o in una manutenzione frettolosa, perché il scenario si riapra. La disinstallazione vera è l'unica pulizia completa.

I numeri che non tornano: solo il 35% ha aggiornato

Ripetiamolo, perché è il dato più preoccupante dell'intera vicenda: la patch esiste dal 20 agosto, la notizia è pubblica da ieri, e comunque circa il 65% delle installazioni non ha aggiornato. Tre milioni e mezzo di siti in ritardo su un update che richiede un click.

Non è stanchezza, è la norma. Lo stesso pattern l'ho visto con le vulnerabilità di plugin popolari degli ultimi anni: la patch esiste, la CVE è pubblica, e la coda degli aggiornamenti si sgombera in settimane — mentre gli scanner automatici degli attaccanti indicizzano le versioni vulnerabili in ore. La finestra tra "fix disponibile" e "fix applicato" è l'unico terreno dove l'attaccante ha davvero un vantaggio, e su 3,25 milioni di siti è un campo coltivato.

Se gestisci siti per clienti, questo è anche l'argomento con cui convincerli a un piano di manutenzione: non è paranoia, è statistica. Il mio servizio di assistenza WordPress esiste esattamente per chiudere questa finestra il prima possibile, su ogni sito, ogni settimana.

E il contesto generale non aiuta: il report Patchstack sul 2026 ha contato oltre 11.300 vulnerabilità nel solo ecosistema plugin, con una crescita del 42% rispetto all'anno precedente e una finestra media di sfruttamento degli attacchi di massa che si misura in cinque ore dalla disclosure. Tradotto: nel 2026, quando esce la CVE, il timer parte subito. La coda degli aggiornamenti non può più essere gestita "quando c'è tempo".

Verifica il tuo sito adesso: tre comandi

Se hai accesso SSH o WP-CLI, la verifica prende meno di un minuto:

# Elenco plugin con versione e stato di aggiornamento
wp plugin list --fields=name,status,version,update

# Verifica specifica del plugin
wp plugin list --search=all-in-one-wp-migration --fields=name,version,update

# Aggiornamento immediato alla 7.110
wp plugin update all-in-one-wp-migration

Senza WP-CLI, dalla dashboard: Plugin → Plugin installati, cerca All-in-One WP Migration. Se la versione è inferiore alla 7.110, aggiornare subito. Se il plugin è disattivato e non ti serve, disinstallalo — non lasciarlo "dormire" nella lista.

Un consiglio da chi ha visto cosa resta dopo un sito WordPress hackerato: se il tuo sito ha subito export/import negli ultimi mesi e il plugin era alla versione vulnerabile, vale la pena fare una scansione di controllo — file di upload inusuali, utenti admin sconosciuti, plugin sconosciuti nella cartella mu-plugins. Se non hai modo di fare questi controlli o preferisci un secondo sguardo, la verifica completa è il primo intervento dell'assistenza WordPress che offro ai nuovi clienti.

Cosa fare se non puoi aggiornare subito

A volte aggiornare non è immediato: siti in staging con modifiche in corso, ambienti cliente con procedure di rilascio lente. In questi casi, l'ordine delle priorità che uso è questo:

• Se il plugin è attivo: aggiornare è l'unica vera soluzione; ogni giorno di attesa è rischio aggiunto. Se proprio non puoi, disattivalo — e verifica che nessun altro processo lo riattivi
• Se il plugin è inattivo ma presente: disinstallalo. Un plugin disattivato non protegge da nulla e può essere riattivato da una manutenzione frettolosa
• Dove il plugin è necessario: attivare l'aggiornamento automatico di quel singolo plugin, e verificare la patch entro la giornata
• In tutti i casi: disattivare i trackback dalle impostazioni di discussione di WordPress se non li usi — è la porta usata per piantare i dati truccati, e la stragrande maggioranza dei siti moderni non ne ha alcun bisogno

Quest'ultimo punto, dettutto dai dettagli tecnici della CVE, vale per tutti: apri Impostazioni → Discussione e togli la spunta a "Consenti i link di notifica da altri blog". Sono anni che consiglio di chiudere quella porta, ed è raro che qualcuno se ne penta.

La lezione vera: la patch velocity dei plugin

La storia di All-in-One WP Migration non dice "i plugin di backup sono pericolosi". Dice che il numero di plugin non è la metrica giusta; la velocità con cui li aggiorni lo è. Un plugin di backup cinque stelle aggiornato entro 48 ore dalla patch è più sicuro di un plugin "leggero" abbandonato da due anni.

Le regole di gestione che applico nel 2026, dopo anni di incidenti visti in prima persona:

• Auto-update per i plugin di sicurezza e backup: la loro funzione stessa li rende obiettivo prioritario, e un minor rischio di rottura da update
• Aggiornamenti settimanali con log: non "quando si può", ma un orario fisso — se aggiornare è un evento programmato, verificare è naturale
• Caccia ai plugin inutilizzati: ogni plugin disattivato e non usato è superficie d'attacco gratis. Cancellarlo costa due minuti
• Vigilanza su ciò che installi: preferire plugin con commit recenti, compatibilità dichiarata con la versione corrente di WordPress e un track record di fix tempestivi. I plugin piratati o nulled sono un capitolo a parte — e pure brutto
• Monitoraggio delle CVE dei plugin installati: WPScan, Wordfence o un servizio di manutenzione — qualcosa che ti dica "questo plugin che usi ha una falla nuova" il giorno stesso, non tre settimane dopo

Hardening minimo che consiglio nel 2026

Se questa notizia ti ha allarmato, ecco il minimo strutturale che metterei su qualsiasi sito WordPress di produzione, indipendentemente dalla notizia del giorno: 2FA su tutti gli account amministrativi, trackback disattivati, auto-update per plugin di sicurezza, un piano di backup con prova di ripristino trimestrale e un inventory dei plugin tenuto in ordine — versione, ultima patch, decisione se serve davvero.

E se la lista ti sembra il lavoro che non troverai mai il tempo di fare, è il momento di delegare: l'assistenza WordPress specializzata copre proprio questo strato di gestione, con patch applicate in giorni e verifiche periodiche. La vulnerabilità di ieri ha un numero: 3,25 milioni. La tua parte per non esserci dentro: un aggiornamento.

Domande frequenti

Ho aggiornato alla 7.110, ma ho fatto export nei mesi scorsi con la versione vulnerabile. Rischio qualcosa?

La vulnerabilità richiede che i dati truccati siano stati piantati via trackback prima dell'export, e che l'attaccante sia poi riuscito a intercettare la chiave segreta. Se il tuo sito ha i trackback attivi e ha fatto export pubblici negli ultimi mesi, una scansione (WPScan o audit manuale dei file recenti) è prudente. In caso di dubbi, meglio un'ora di verifica che un weekend di restoration.

Meglio disinstallare All-in-One WP Migration e passare a un altro plugin?

No: la versione 7.110 chiude la falla. Se il plugin ti è utile, aggiornalo e tienilo aggiornato. Un plugin di backup patchato in 5 giorni dallo sviluppatore è, se mai, un buon segno di patch velocity. Quello che non perdonerei è un plugin di backup senza auto-update e senza manutenzione: in quel caso valuta alternative con più cerca-attenzioni.

I backup che ho esportato prima della patch sono "infetti"?

Solo se il sito era già stato compromesso con la tecnica descritta: l'archivio in sé non contiene l'attacco, contiene il database. Se l'archivio è stato creato quando i dati truccati erano presenti e la chiave è stata esposta, l'archivio potrebbe contenere quei dati. Ripristinarlo su un sito pulito senza controllare i contenuti è il rischio concreto.

Che strumenti devo attivare per non scoprirlo dai giornali?

Minimo: WPScan o Wordfence con notifiche attive, aggiornamento automatico per plugin di sicurezza, e un servizio di manutenzione che applica le patch in giorni. Se vuoi delegare tutto il flusso — monitoraggio, patch, verifica, report — è esattamente il lavoro quotidiano del mio servizio di assistenza WordPress.

Riferimenti utili

• WordPress backup plugin flaw exposes millions of sites — BleepingComputer
• 5 million WordPress sites affected by SQL injection in All-in-One WP Migration — Wordfence
• All-in-One WP Migration — statistiche installazioni su WordPress.org
• WordPress hackerato: guida al ripristino e alla sicurezza
• Plugin piratati e sicurezza WordPress: i rischi reali
• Assistenza WordPress: monitoraggio e patch gestite