Vulnerabilità nel plugin GiveWP consente l'esecuzione remota di codice non autenticata

Una vulnerabilità nel plugin di donazioni WordPress GiveWP ha permesso a un malintenzionato senza account di eseguire comandi arbitrari sul server web sottostante, secondo un advisory di sicurezza di Patchstack. GiveWP è un plugin popolare che fornisce moduli di donazione, gateway di pagamento, gestione dei donatori e reportistica per organizzazioni non profit e altre organizzazioni di raccolta fondi. La falla, tracciata come CVE-2026-82222, ha ricevuto un punteggio di gravità CVSS di 10.0, il massimo possibile. Ha interessato le versioni di GiveWP 4.16.7.1 e precedenti, ed è stata corretta nella versione 4.16.7.2, rilasciata il 27 agosto 2026. Patchstack, un'azienda di sicurezza WordPress, ha dichiarato che i suoi utenti erano protetti da regole di mitigazione e che il problema è stato scoperto e segnalato dal ricercatore Udin Chan. L'advisory elenca il plugin con circa 100.000 installazioni, rendendo l'aggiornamento urgente per molti proprietari di siti.

Il problema tecnico è noto come iniezione di oggetti PHP. I siti web basati su WordPress e PHP spesso memorizzano dati complessi come stringhe di testo, un processo chiamato serializzazione, e successivamente riconvertono quella stringa in un oggetto programma vivo tramite una funzione chiamata unserialize. Se un malintenzionato può controllare il testo serializzato, l'applicazione PHP può essere ingannata per creare un oggetto pericoloso che esegue codice scelto dall'attaccante. GiveWP ha cercato di rendere sicuro questo processo con una funzione helper chiamata safeUnserialize, che utilizzava l'opzione PHP allowed_classes impostata su false. Tuttavia, questa opzione non elimina l'oggetto dell'attaccante. Invece, converte l'oggetto in un segnaposto chiamato __PHP_Incomplete_Class che mantiene il nome della classe originale e tutte le sue proprietà. Quando quel segnaposto viene successivamente serializzato di nuovo, PHP riscrive i byte pericolosi originali senza modifiche. Come spiega l'advisory di Patchstack, l'helper nascondeva il payload per una lettura e poi restituiva l'oggetto serializzato intatto all'archiviazione, quindi l'attacco avveniva semplicemente alla successiva lettura non protetta.

Il primo passo dell'attacco richiede un donatore autenticato. Sembra una barriera, ma i ricercatori hanno descritto un modo per ottenere un account gratuitamente. GiveWP espone un'azione di registrazione non autenticata chiamata give_action=user_register, che non controlla mai l'impostazione di WordPress che determina se i visitatori possono registrarsi. Anche su un sito con registrazione disabilitata, un malintenzionato potrebbe inviare una richiesta appositamente predisposta per creare un account e ricevere un cookie di autenticazione. Prima della versione 4.16.6 non c'era alcun requisito di nonce su questo handler. Un nonce è un token temporaneo progettato per dimostrare che una richiesta proviene da una pagina autorizzata. La versione 4.16.6 ha aggiunto un requisito di nonce, ma il nonce viene emesso solo da una pagina che utilizza lo shortcode [give_register], e i nonce di WordPress per i visitatori non autenticati sono identici per ogni richiesta anonima allo stesso sito. Ciò significa che un malintenzionato può raccogliere il nonce una volta e riutilizzarlo su qualsiasi sito che visualizzi pubblicamente quello shortcode. In breve, la barriera dell'account non era una vera barriera.

Una volta dentro, l'attaccante inserisce una catena di gadget serializzata nel campo del cognome del proprio account tramite la pagina del profilo. Il termine catena di gadget si riferisce a una sequenza di metodi nel codice già caricato che, quando un oggetto viene distrutto o serializzato, alla fine chiama una funzione pericolosa. GiveWP include due librerie che insieme formano una catena completa: la libreria TCPDF e le classi Give\TestData. Quando l'oggetto iniettato viene distrutto, entra in TCPDF::__destruct, che chiama _destroy, e questo raggiunge un metodo magico nel trait ProviderForwarder. Quel metodo usa call_user_func_array con un callable e un argomento controllati dall'attaccante. Poiché l'attaccante controlla una proprietà array chiamata loadedProviders all'interno dell'oggetto iniettato, può impostarla sulla funzione di sistema PHP. Il risultato è l'esecuzione di un comando arbitrario del sistema operativo come utente del server web.

Il flusso di donazione collega questi pezzi. Quando l'attaccante autenticato invia una donazione, il plugin costruisce un record informativo del donatore. Prende il valore last_name dal database, dove è stato memorizzato il gadget serializzato, e lo esegue attraverso l'helper unserialize "sicuro". Poiché i dati provengono dal database piuttosto che direttamente dalla richiesta, la normale validazione dell'input non li vede mai. L'oggetto segnaposto viene quindi serializzato mentre viene inserito nella tabella wp_give_sessions, e i byte pericolosi originali vengono memorizzati intatti. La prossima volta che il sito legge quella sessione, unserializza i byte senza la protezione allowed_classes, portando in vita il vero gadget. La catena completa descritta da Patchstack ha quattro passaggi: registrare un account, inserire il gadget nel profilo, avvelenare la sessione inviando una donazione senza un valore last_name, e quindi richiedere qualsiasi pagina front-end con lo stesso cookie per attivare il comando.

L'advisory spiega anche un cambiamento di raggiungibilità tra le versioni. Su GiveWP 4.16.5.1 e precedenti, un'installazione predefinita era sufficiente: il plugin veniva fornito con un gateway manuale attivo (Test Donation) e un gateway offline attivo, e richiedeva solo un modulo di donazione pubblicato. Nessuna modalità di test, registrazione aperta, modalità di debug o azione amministratore era richiesta. Le versioni 4.16.6 fino alla 4.16.7.1 facevano sì che il processore di donazioni legacy si interrompesse quando il modulo inviato era un modulo Visual Form Builder (v3), quindi una nuova installazione predefinita non era più sfruttabile attraverso quel percorso. Tuttavia, un singolo post give_forms privo di formBuilderSettings riattiva la catena, in qualsiasi stato del post, inclusi bozza e cestino. Questo copre i siti aggiornati da versioni precedenti, qualsiasi importazione o ripristino di moduli, e qualsiasi sito in cui un amministratore ha abilitato l'Option-Based Form Editor.

La patch include un'importante lezione sui difetti di deserializzazione. Prima della correzione finale, GiveWP ha rilasciato la versione 4.16.6, che tentava di rilevare il segnaposto __PHP_Incomplete_Class e, quando trovato, restituire la stringa serializzata grezza. Questo restituiva i byte del payload originale verbatim, lasciando l'attacco altrettanto possibile in seguito. La versione 4.16.7.2 ha cambiato questo comportamento restituendo false, il che ferma il payload. Gli sviluppatori hanno poi chiuso la catena in cinque punti indipendenti. Il percorso di scrittura in process-donation.php ora rifiuta una donazione direttamente se qualsiasi campo del nome contiene dati serializzati, e il fallback dei meta utente passa attraverso give_clean, che restituisce una stringa vuota per input serializzati. Tre sink di lettura ora passano allowed_classes impostato su false: il getter della sessione, la lettura della tabella delle sessioni e il muro dei donatori. Il muro dei donatori è importante perché era raggiungibile da un visitatore anonimo tramite lo shortcode pubblico [give_donor_wall] senza alcun cookie di sessione. Il gadget stesso è stato corretto: ProviderForwarder::__call ora verifica che il provider risolto implementi il contratto previsto prima di chiamarlo. I meta dei nomi di donatori e fatturazione vengono passati attraverso sanitize_text_field quando i pagamenti vengono salvati. Infine, una migrazione chiamata SanitizeSerializedObjectPayloads esamina usermeta, give_donormeta, give_donationmeta e give_sessions e sostituisce qualsiasi oggetto annidato con una stringa vuota. Questo ultimo passaggio rimuove i payload già memorizzati nel database prima dell'aggiornamento.

L'advisory nota un elemento del rapporto che non viene affrontato. L'handler di registrazione non autenticato give_action=user_register non consulta ancora l'opzione WordPress users_can_register. Patchstack descrive questo come un problema di controllo degli accessi piuttosto che un passo verso l'esecuzione di codice una volta chiusa l'iniezione di oggetti. I proprietari dei siti dovrebbero comunque tenerlo a mente, ma la catena di esecuzione remota del codice stessa è interrotta dai cinque livelli di correzione. La cronologia mostra che il rapporto è stato ricevuto il 28 luglio 2026, confermato lo stesso giorno e divulgato al fornitore. Diversi tentativi di patch sono stati respinti prima del rilascio della versione 4.16.7.2 del 27 agosto 2026. L'advisory è stato reso pubblico il 28 agosto 2026.

Per i proprietari di siti web, questo caso è un promemoria che un plugin con una grande base di installazione e funzionalità di pagamento è un bersaglio primario. Aggiornate GiveWP e ogni plugin attivo tempestivamente e trattate gli aggiornamenti di sicurezza come manutenzione sensibile al tempo. I servizi di hosting WordPress gestiti che mantengono i plugin aggiornati, come AEU Hosting, possono ridurre il tempo in cui una versione vulnerabile rimane attiva su un sito di produzione. Questa è una protezione pratica per le molte organizzazioni non profit, raccolte fondi e piccole imprese che si affidano a GiveWP per raccogliere donazioni online.