Una falla in GiveWP consente agli attaccanti di eseguire codice sui siti WordPress

GiveWP, un plugin WordPress per donazioni e raccolta fondi, contiene una vulnerabilità che consente a un attaccante senza alcun account sul sito di eseguire comandi sul server, secondo un articolo di avviso pubblicato da Patchstack il 28 agosto 2026. Le versioni di GiveWP 4.16.7.1 e precedenti sono interessate. Il fornitore ha rilasciato la versione 4.16.7.2 il 27 agosto 2026 per risolvere il problema, e all'segnalazione è stato assegnato l'identificativo CVE-2026-82222. Patchstack indica il plugin con 100.000 installazioni e valuta la falla con CVSS 10.0, il massimo di quella scala di gravità.

Il ricercatore Udin Chan ha scoperto la falla e l'ha segnalata, secondo Patchstack, che afferma di aver confermato il problema e contattato il fornitore. Patchstack afferma inoltre di aver emesso regole di mitigazione per proteggere dallo sfruttamento di questa vulnerabilità. GiveWP è utilizzato da organizzazioni no-profit e altre organizzazioni per gestire moduli di donazione, collegare gateway di pagamento, gestire donatori e produrre report.

Ciò che rende questo problema grave è quanto poco serva a un attaccante. Nelle versioni 4.16.5.1 e precedenti, è sufficiente un'installazione predefinita, perché GiveWP viene distribuito con un gateway manuale (Test Donation) attivo e un gateway offline attivo, ed è richiesto solo un modulo di donazione pubblicato. Non sono necessari Test Mode, registrazione utenti aperta, modalità debug o azioni dell'amministratore. Una volta che la catena si attiva, un attaccante può eseguire un comando arbitrario del sistema operativo come l'utente con cui gira il server web, e l'output di quel comando può essere letto via HTTP.

Un'installazione predefinita ha smesso di essere sufficiente nelle versioni dalla 4.16.6 alla 4.16.7.1, ma solo nel senso della raggiungibilità, non perché il problema di fondo fosse stato risolto. Quelle versioni fanno fermare il vecchio processore di donazioni quando il modulo inviato è un modulo Visual Form Builder (v3). Patchstack osserva che una singola voce di modulo priva delle sue impostazioni di form builder riattiva l'intera catena, e che questa può trovarsi in qualsiasi stato del post, inclusi bozza e cestino. Questo riguarda ogni sito aggiornato da una versione precedente, qualsiasi importazione o ripristino di modulo, e qualsiasi sito in cui un amministratore abbia attivato l'Option-Based Form Editor in Impostazioni, Avanzate.

La vulnerabilità è costruita da tre parti. La prima è un helper che GiveWP intendeva come modo sicuro di usare unserialize, la funzione PHP che trasforma un blocco di testo memorizzato in oggetti di programmazione vivi. Se un attaccante controlla quel testo, può inserire un oggetto di una classe da lui scelta. L'helper nel file src/Helpers/Utils.php chiama unserialize con l'impostazione allowed_classes impostata su false, che sembra indicare che gli oggetti siano bloccati. In pratica PHP crea comunque l'oggetto, ma come tipo segnaposto chiamato __PHP_Incomplete_Class che conserva il nome della classe originale e ogni proprietà. Quando quel segnaposto viene riscritto nella memoria, PHP riemette gli stessi byte originali, quindi il payload non viene neutralizzato, solo nascosto durante quella singola lettura. L'attacco è semplicemente rinviato a una lettura successiva che avviene senza la protezione.

La seconda parte è un flusso di donazione che consegna dati controllati dall'attaccante a quell'helper. Un donatore autenticato può memorizzare un oggetto serializzato nel campo cognome del proprio profilo utente. Quando invia una donazione, il codice di elaborazione della donazione in includes/process-donation.php costruisce le informazioni del donatore da quei dati dell'account e passa ogni campo attraverso l'helper di unserialize sicuro prima di salvare il risultato nella tabella wp_give_sessions. Poiché i dati malevoli tornano dal database invece di arrivare direttamente nella richiesta, la normale validazione dell'input non li vede mai, e il segnaposto che porta i byte originali finisce intatto nel database.

La terza parte è una gadget chain, ovvero una sequenza di metodi in classi già caricate che termina in una chiamata a una funzione pericolosa. GiveWP include sia la libreria TCPDF sia le proprie classi di dati di test, e insieme formano un percorso completo. Distruggere l'oggetto iniettato entra nel distruttore di TCPDF, che chiama un metodo interno destroy, che raggiunge un metodo di inoltro nel trait ProviderForwarder che passava i suoi argomenti direttamente in call_user_func_array usando un callable preso dall'oggetto stesso. Poiché l'elenco dei provider è solo una proprietà array contenuta nell'oggetto iniettato, l'attaccante può puntarla a qualsiasi funzione, inclusa una che esegue comandi del sistema operativo.

La catena richiede anche un utente autenticato, e GiveWP ne forniva uno gratuitamente. Patchstack segnala che un'azione di registrazione non autenticata, give_action=user_register, non controlla mai l'impostazione di WordPress che regola se i visitatori possono registrarsi. Anche su un sito con la registrazione disattivata, un attaccante poteva creare un account, ricevere un cookie di autenticazione e continuare immediatamente. La versione 4.16.6 ha aggiunto a quel gestore un requisito di codice monouso, che restringe la finestra invece di chiuderla: il codice viene emesso solo dal template dello shortcode di registrazione, e WordPress rilascia codici monouso identici a tutti i visitatori non autenticati di un dato sito, quindi su qualsiasi sito che mostri quello shortcode pubblicamente un attaccante può raccogliere un codice e riutilizzarlo.

In sequenza, l'attacco segnalato aveva quattro passaggi. Primo, registrare un account inviando una richiesta all'azione di registrazione, che restituisce un cookie di autenticazione indipendentemente dalla politica di registrazione del sito. Secondo, leggere un codice profilo dalla pagina del profilo e inserire il gadget serializzato nel campo cognome dell'account. Terzo, recuperare un codice di donazione e inviare una donazione con id modulo, gateway e importo ma senza il campo cognome, il che fa scrivere al server l'oggetto nella tabella delle sessioni prima di restituire un errore HTTP 500. Quarto, richiedere qualsiasi pagina front-end con lo stesso cookie, momento in cui il server legge la sessione avvelenata, ricostruisce l'oggetto ed esegue il comando dell'attaccante.

GiveWP ha risolto il problema nella 4.16.7.2, e Patchstack sottolinea che la correzione spezza la catena in diversi punti indipendenti invece che nell'unico punto di ingresso segnalato. Un tentativo precedente nella 4.16.6 mostra perché questo conta: rilevava il segnaposto incompleto e restituiva il testo serializzato grezzo, che preservava il payload esattamente come prima. La versione 4.16.7.2 restituisce invece un valore di errore. Il rilascio poi chiude cinque punti: il codice di elaborazione della donazione rifiuta del tutto una donazione se qualsiasi campo nome contiene dati serializzati, e un percorso di fallback dei dati utente viene passato attraverso una funzione di pulizia che restituisce una stringa vuota per l'input serializzato; tre punti che rileggono questi dati ora bloccano la creazione di oggetti, incluso il donor wall, che era raggiungibile da un visitatore anonimo tramite uno shortcode pubblico senza alcun cookie; il gadget di inoltro ora controlla che il provider che risolve implementi effettivamente il contratto atteso; i campi nome del donatore e di fatturazione vengono sanificati prima di essere memorizzati; e una migrazione chiamata SanitizeSerializedObjectPayloads percorre le tabelle dati di utenti, donatori, donazioni e sessioni e sostituisce qualsiasi oggetto annidato con una stringa vuota. Quest'ultimo passaggio conta perché un sito avvelenato prima dell'aggiornamento altrimenti manterrebbe un payload funzionante nel suo database.

Un problema della segnalazione resta aperto. Patchstack afferma che l'azione di registrazione continua a non consultare l'impostazione del sito che consente le registrazioni, e la caratterizza come un problema di controllo degli accessi piuttosto che come un passo verso l'esecuzione di codice ora che l'iniezione di oggetti è chiusa. La cronologia registrata da Patchstack va dal 28 luglio 2026, quando è arrivata la segnalazione che copriva le versioni 4.16.5.1 e precedenti e fu assegnato il CVE, al 27 agosto 2026, quando il fornitore ha rilasciato la 4.16.7.2, fino al 28 agosto 2026, quando è stato pubblicato l'avviso.

Per i proprietari dei siti la lezione pratica è la tempestività delle patch. L'aggiornamento è disponibile, rimuove il codice vulnerabile e pulisce anche i dati che le versioni precedenti potrebbero aver già memorizzato. Per chi preferisce non seguire i livelli di patch plugin per plugin, AEU Hosting, il nostro servizio di hosting WordPress gestito, si occupa della manutenzione e della sicurezza di WordPress come parte del piano, che è esattamente il livello in cui una correzione come questa deve arrivare rapidamente.