Una falla del plugin Backuply WordPress consente il site takeover
Una vulnerabilità del plugin Backuply WordPress può consentire a un aggressore con un normale account subscriber di inserire istruzioni dannose per il database che vengono eseguite in seguito, quando un amministratore ripristina un backup. Wordfence afferma che la falla interessa tutte le versioni di Backuply fino alla 1.5.8 inclusa, esponendo potenzialmente più di 600.000 installazioni attive. La release con la correzione completa è la versione 1.5.9.
Il problema è identificato come CVE-2026-93953 e ha un punteggio di 8,0 nel Common Vulnerability Scoring System (CVSS), classificato come High. CVSS è una scala standard per descrivere la gravità di una falla di sicurezza. Si tratta di una second-order SQL injection: i comandi ostili per il database vengono salvati durante un'operazione, ma vengono eseguiti soltanto quando un'operazione separata elabora successivamente il contenuto memorizzato.
Secondo Wordfence, un aggressore autenticato con accesso di livello subscriber o superiore può inserire il payload nel campo Biographical Info del proprio profilo WordPress. WordPress memorizza la biografia come testo semplice nella tabella wp_usermeta. Backuply la include quindi come valore tra virgolette sottoposto a escape durante la creazione di un SQL dump, ossia un file contenente i comandi per il database utilizzati per ricostruirlo. In questa fase, la biografia viene memorizzata come dato e l'attacco non è ancora stato eseguito.
Il passaggio pericoloso avviene durante il ripristino. Backuply esegue ogni istruzione completa contenuta nel dump e utilizza una regular expression non ancorata, cioè una regola di corrispondenza del testo non limitata all'inizio dell'istruzione, per identificare il vecchio table prefix di WordPress. Un table prefix è la parte iniziale condivisa dai nomi delle tabelle del database di WordPress, come la parte che precede “options”. Wordfence ha scoperto che l'espressione non è limitata a un'autentica intestazione CREATE TABLE e non ignora i valori tra virgolette, quindi può trovare una corrispondenza con testo appositamente preparato all'interno della biografia memorizzata.
Se la stessa istruzione contiene la stringa backuply_version, il testo acquisito come presunto table prefix viene inserito in una seconda query UPDATE senza alcuna convalida. Un aggressore può quindi costruire la biografia in modo che il materiale acquisito sia un'istruzione UPDATE completa per il database anziché un vero prefix. Un carattere di commento alla fine fa sì che il testo rimanente della query del plugin venga ignorato, lasciando che l'istruzione controllata dall'aggressore venga eseguita con privilegi completi sul database.
Il payload dimostrato modifica due record nella tabella wp_options. Imposta default_role su administrator e users_can_register su 1. La prima impostazione assegna il ruolo administrator a un nuovo account quando non viene indicato esplicitamente alcun ruolo, mentre la seconda abilita la registrazione pubblica degli utenti. Wordfence osserva che wp_options viene ripristinata prima di wp_usermeta, quindi le impostazioni modificate sono già presenti quando viene eseguita la query inserita e rimangono attive al termine del ripristino.
Dopo il ripristino, l'aggressore può utilizzare il normale modulo di registrazione di WordPress per creare un altro account. Poiché la registrazione è aperta e il ruolo predefinito è administrator, tale account ottiene il pieno controllo amministrativo del sito. La query inserita viene eseguita all'interno di un'operazione INSERT e non restituisce alcuna risposta all'aggressore; questa tecnica viene quindi utilizzata per modificare i record del database anziché per recuperare direttamente le informazioni esistenti.
Esiste un prerequisito importante: l'amministratore deve ripristinare un backup del database creato dopo il salvataggio della biografia dannosa. Il semplice inserimento della biografia non esegue l'SQL. Wordfence considera comunque significativo questo scenario perché la creazione e il ripristino dei backup sono la funzione principale di Backuply, rendendo il ripristino una normale attività amministrativa.
Wordfence ha ricevuto la segnalazione tramite il proprio Bug Bounty Program il 17 settembre 2026, ha convalidato il proof of concept il 19 settembre e ha corrisposto al ricercatore 1.352 dollari. Il 24 settembre ha fornito agli utenti di Wordfence Premium, Wordfence Care e Wordfence Response una firewall rule contro gli exploit noti. Una firewall rule è un'istruzione di filtraggio progettata per bloccare le richieste dannose corrispondenti. Wordfence ha comunicato la vulnerabilità al team di Backuply il 28 settembre e lo sviluppatore ha pubblicato la versione 1.5.9 il 1° ottobre. Per i siti che utilizzavano l'edizione gratuita di Wordfence era prevista la distribuzione della stessa rule il 24 ottobre, 30 giorni dopo le edizioni a pagamento.
Gli amministratori devono aggiornare Backuply alla versione 1.5.9 o successiva prima di ripristinare un backup del database. Devono inoltre controllare le impostazioni di registrazione di WordPress e gli account amministratore, in particolare se è stato ripristinato un backup mentre era installata una versione vulnerabile. Una firewall rule può fornire un ulteriore livello di difesa, ma non sostituisce l'installazione della release corretta del plugin.
Per i proprietari di siti che preferiscono non gestire autonomamente la sicurezza di WordPress, AEU Hosting offre hosting WordPress gestito e protetto end to end. Indipendentemente dalla soluzione di hosting, la risposta diretta a questa falla consiste nel sostituire Backuply 1.5.8 o una versione precedente con la versione corretta e nel controllare il sito alla ricerca di accessi amministrativi imprevisti.