Eliminare le UpdraftCentral keys dopo la presa di controllo di siti WordPress
Le UpdraftCentral keys rubate dal servizio di remote management vengono utilizzate per installare backdoor sui siti WordPress connessi. Patchstack ha dichiarato che la campagna è rimasta continuamente operativa durante una finestra di 18 ore il 18 e 19 ottobre 2026, con la prima installazione registrata alle 15:32 del 18 ottobre e la più recente alle 09:23 del giorno successivo. L'aggiornamento di stato delle 08:00 UTC indicava che lo sfruttamento era ancora attivo e che non esisteva alcuna correzione del fornitore. TeamUpdraft ha pubblicato un post sull'incidente di sicurezza alle 13:00 UTC.
Si tratta di una compromissione delle credenziali, non di una vulnerabilità nel codice di UpdraftPlus, quindi installare la versione più recente del plugin non ferma l'attacco. Tutte le versioni gratuite e premium di UpdraftPlus sono interessate quando un sito dispone di una connessione UpdraftCentral attiva, incluse le release 1.26.11 e 2.26.11. Patchstack ha assegnato all'incidente un punteggio CVSS di 9,8, utilizzando la scala Common Vulnerability Scoring System per misurare la gravità dei problemi di sicurezza. UpdraftPlus conta più di quattro milioni di installazioni attive, anche se questa campagna espone soltanto i siti che conservano una UpdraftCentral key.
UpdraftCentral è un servizio di remote management separato, il cui client è incluso in ogni installazione di UpdraftPlus. Il client rimane inattivo finché un sito non riceve una credenziale di connessione. A quel punto, il sito crea un RSA key pair, ossia un insieme abbinato utilizzato per verificare istruzioni cifrate, e memorizza la parte pubblica della dashboard. Eseguirà quindi i comandi firmati dalla parte privata corrispondente con le autorizzazioni dell'utente WordPress che ha stabilito la connessione. I singoli comandi non richiedono ulteriori conferme.
Un sito può ricevere una credenziale di questo tipo entrando in una dashboard UpdraftCentral o collegandosi a un account TeamUpdraft.com. Nella schermata dell'account, l'opzione per aggiungere il sito web al controllo remoto centralizzato è selezionata per impostazione predefinita. L'opzione compare soltanto se non esiste già una credenziale, quindi una singola connessione riuscita dell'account può registrare un sito il cui proprietario non intendeva consapevolmente utilizzare UpdraftCentral. Patchstack ha dichiarato che le credenziali emesse nel novembre 2025 erano ancora valide nell'ottobre 2026 perché non scadono. Le credenziali private della dashboard rimangono nel servizio cloud anziché sui siti web connessi.
L'attaccante invia un'istruzione plugin.upload_plugin validamente firmata attraverso il canale di comando remoto, che accetta normali POST requests, ossia dati inviati al sito web. WordPress installa e attiva quindi il plugin fornito attraverso il proprio programma di installazione standard. Nethemba, che ha individuato la campagna su tre siti della propria infrastruttura e pubblicato la prima analisi, ha riferito che i file locali del plugin corrispondevano alle release ufficiali, che i fingerprint delle credenziali non erano cambiati nei backup di più giorni, che la crittografia funzionava correttamente e che i logs non mostravano né un amministratore non autorizzato né un caricamento convenzionale del plugin. Le richieste ostili provenivano da un'infrastruttura controllata dall'attaccante, anziché dai normali sistemi del servizio. Le prove indicavano quindi che le credenziali erano fuoriuscite dall'ambiente UpdraftCentral Cloud, ma TeamUpdraft non aveva ancora spiegato la causa quando Patchstack ha pubblicato i propri risultati.
Ogni plugin caricato contiene una backdoor che viene eseguita nelle prime fasi di ogni richiesta WordPress e attende un parametro URL segreto contenente un valore di 32 caratteri. Se il parametro viene fornito, la backdoor crea un account con una password incorporata e lo etichetta come Editor. Concede poi separatamente manage_options e install_plugins, due WordPress capabilities che permettono di modificare le impostazioni e installare codice eseguibile sotto forma di plugin. Il visitatore viene autenticato tramite un cookie persistente del browser e reindirizzato a wp-admin senza passare dal modulo di login. Ciò aggira la two-factor authentication, i limiti ai tentativi di login e i plugin di protezione del login.
L'account camuffato rimane dopo la rimozione del plugin dannoso e l'attaccante ne conosce già la password. I campioni analizzati contenevano un errore di programmazione che causava un HTTP 500 server error prima che potesse essere eseguito il controllo di attivazione, facendo fallire ogni richiesta di pagina non memorizzata nella cache. Questa interruzione visibile ha avvisato le prime vittime nel giro di pochi minuti. I proprietari dei siti non devono correggere il codice dannoso, perché la correzione dell'errore ne attiverebbe il comportamento previsto.
Patchstack ha registrato 99 nomi diversi di plugin. “Site Health Cache” è comparso ripetutamente, mentre la maggior parte degli altri nomi era costituita da combinazioni casuali di due o tre parole utilizzate una sola volta. L'indicatore più affidabile è la descrizione identica “Small maintenance toolkit: keeps option storage tidy.” Tra gli account confermati figurano data-ops43 e media-staff96, ma è prevedibile che vengano utilizzati anche altri nomi. Ulteriori segnali includono un indirizzo che termina con @example.org, il nome visualizzato “Site Tools”, un'opzione del database che termina con _sync_token, email di errore WordPress sconosciute e installazioni di plugin senza una corrispondente azione dell'amministratore.
Le richieste osservate provenivano da 43.250.53.42 e 2a09:bac5:4e21:2e3c::49b:9. L'indirizzo IPv6 è comparso circa tre ore prima dell'indirizzo IPv4 ed entrambi hanno operato contemporaneamente. Poiché l'attaccante ha cambiato infrastruttura nell'arco di un solo giorno, bloccare questi indirizzi non costituisce una difesa adeguata. Il traffico remoto legittimo include una versione della libreria e l'URL del servizio nel proprio identificativo User-Agent; le richieste ostili omettevano entrambi. I logs di UpdraftCentral possono inoltre mostrare probe.central.updraftplus.com seguito da “Command received: plugin.upload_plugin.”
Gli amministratori devono verificare la presenza di una connessione anche se utilizzano UpdraftPlus soltanto per i backup. Con WP-CLI, lo strumento da riga di comando per amministrare WordPress, eseguire wp option get updraft_central_localkeys. Qualsiasi output indica la presenza di una credenziale. In wp-admin, è possibile rimuoverla accedendo a Settings, UpdraftPlus Backups, Advanced Tools, UpdraftCentral, quindi a “Manage existing keys” ed eliminando ogni voce. L'alternativa tramite WP-CLI è wp option delete updraft_central_localkeys. Rimuovere il sito web soltanto dalla dashboard centrale non è sufficiente, perché la copia pertinente rimane sul sito. I backup pianificati continuano dopo l'eliminazione; si interrompe soltanto il remote management.
Se viene trovata una backdoor, rimuovere prima la credenziale UpdraftCentral, in modo che l'attaccante non possa inviarne una sostitutiva. Disattivare il plugin e spostarlo fuori dalla directory accessibile dal web invece di eliminarlo tramite wp-admin, perché il suo processo di disinstallazione rimuove le proprie tracce. Eliminare l'opzione _sync_token associata e l'account nascosto. Se tale account esiste, oppure se gli access logs mostrano il parametro segreto di attivazione, considerare il sito completamente compromesso: ripristinare un backup precedente all'attacco, confrontare i file con un'installazione WordPress pulita, controllare ogni utente dotato di capabilities aggiuntive, cambiare le password degli amministratori e di UpdraftCentral Cloud, terminare tutte le sessioni e abilitare la two-factor authentication. Non ristabilire la connessione finché la causa non sarà stata spiegata. Se il remote management è essenziale, Patchstack osserva che l'utilizzo di un account privo di install_plugins ha impedito l'attacco su un sito analizzato pubblicamente.