Il PoC fornito è intenzionalmente limitato:

• Esegue solo touch /tmp/CVE-2026-82222-RCE-GETBAG.
• Non offre alcuna opzione di comando arbitrario.
• Non crea shell, callback, persistenza o escalation di privilegi.
• Rifiuta target non-loopback a meno che l'operatore non fornisca il flag esplicito --allow-authorized-non-loopback.
• Docker pubblica WordPress solo su 127.0.0.1.
• Il nome del progetto Compose deriva dal percorso di checkout, così un clone non può abbattere i container o i volumi di un altro clone.
• Il laboratorio usa il sorgente ufficiale pulito del plugin; non strumenta né applica patch al target vulnerabile.

Il test HTTP crea un utente donatore usa-e-getta, metadati e righe di sessione GiveWP. Usa il comando di reset incluso dopo il test.

Avvio rapido

Requisiti:

• Docker con Compose v2
• Python 3.10 o successivo
• curl
• unzip
• sha256sum o shasum
• Accesso di rete a downloads.wordpress.org per gli archivi ufficiali del plugin

Esegui la matrice completa vulnerabile/patchata:

Il comando:

1. Scarica GiveWP 4.16.5.1 e 4.16.7.2 da WordPress.org.
2. Verifica entrambi gli hash SHA-256.
3. Costruisce un laboratorio WordPress 6.6.2/PHP 8.1 fresco solo-loopback con la registrazione normale di WordPress esplicitamente disabilitata.
4. Testa il 4.16.5.1 pulito e richiede la creazione del marker da parte dell'utente web.
5. Costruisce un secondo laboratorio fresco con il 4.16.7.2 pulito.
6. Richiede che il marker HTTP rimanga assente.
7. Bypassa l'ingresso in un controllo diretto e conferma che anche il terminale ProviderForwarder patchato rifiuta il callable stringa.

Il laboratorio patchato rimane in esecuzione alla fine. Rimuovilo con:

Per usare un'altra porta loopback:

Evidenza attesa

Il controllo vulnerabile deve terminare con evidenza terminale concreta:

Il controllo patchato deve mostrare:

Un HTTP 500, payload memorizzato, eccezione o hit del rilevatore senza il marker non viene accettato come prova di RCE.

Ciclo di vita manuale del laboratorio

Avvia e testa la release vulnerabile:

Avvia e testa la release patchata:

Ispeziona lo stato corrente:

Rimuovi container, volumi, utenti di test, sessioni e stato del marker:

Gli ZIP del plugin in cache e gli asset estratti vengono conservati per riesecuzioni più veloci. Rimuovi anche quegli asset generati esatti con:

Versioni interessate e testate

L'advisory pubblico identifica le release fino alla 4.16.7.1 come interessate. Questo repository dimostra direttamente solo le due versioni nella sua matrice di test positivo/negativo.

Riferimenti:

• Advisory Patchstack
• CVE-2026-82222
• Commit di hardening GiveWP
• Pagina ufficiale del plugin GiveWP

Causa principale

Lo sfruttamento combina diversi comportamenti:

1. GiveWP 4.16.5.1 espone un'azione di registrazione che crea e autentica un donatore a bassi privilegi anche quando la registrazione normale di WordPress è disabilitata.
2. Quell'utente può persistere dati serializzati nei propri metadati name.
3. Give\Helpers\Utils::maybeSafeUnserialize() usa allowed_classes => false, producendo __PHP_Incomplete_Class, ma una successiva serializzazione preserva i nomi e le proprietà delle classi originali.
4. Il grafo viene memorizzato in una sessione di acquisto GiveWP.
5. Un successivo maybe_unserialize() senza restrizioni riattiva le classi incluse.
6. La distruzione automatica entra in una catena POP completa fino a system().

Sono richieste quattro barre rovesciate letterali del namespace nel vettore HTTP. I due passaggi di stripping effettivi le riducono 4 -> 2 -> 1. Il payload è privo di NUL, e PHP 8.1.30 è stato verificato per idratare il nome serializzato semplice per la proprietà privata Session::$attributeName.

Catena POP completa

Grafo controllato dall'attaccante:

La transizione nascosta critica è il dispatch implicito di IteratorAggregate di PHP. TCPDF::$imagekeys è non tipizzato, quindi assegnare una Session Symfony fa sì che foreach invochi Session::getIterator().

Il comando marker viene eseguito prima che Symfony applichi il tipo di ritorno getAttributeBag(): AttributeBagInterface. Il conseguente TypeError e HTTP 500 sono effetti post-sink.

Cosa hanno mancato i tentativi precedenti

Il grafo candidato rifiutato usava:

Quel grafo non può funzionare. TCPDF::_destroy() esegue solo unset di objcopy; PHP non instrada la distruzione automatica attraverso __call('__destruct', ...).

L'operazione mancante era:

La revisione precedente seguiva i distruttori e le chiamate di metodo esplicite ma non ispezionava ricorsivamente il protocollo implicito degli oggetti attivato da foreach. La Session Symfony fornisce il ponte mancante:

• foreach invoca getIterator().
• getIterator() raggiunge getBag($attributeName).
• Lo storage controllato dall'attaccante è una DonationFactory.
• Il getBag non definito invoca ProviderForwarder::__call().
• loadedProviders['getBag'] = 'system' seleziona il callable.
• attributeName fornisce l'argomento del comando.

Evidenza dal sorgente

Posizioni rilevanti in GiveWP 4.16.5.1:

Hash delle release ufficiali:

Il laboratorio riestrae ogni plugin dal suo ZIP verificato prima di ogni avvio fresco, lo copia in WordPress senza modifiche e confronta byte per byte l'albero completo dei file del plugin distribuito con il sorgente verificato. Le tre immagini Docker base ufficiali sono anche bloccate ai loro digest manifest multi-architettura.

Perché 4.16.7.2 blocca la catena

GiveWP 4.16.7.2 aggiunge difese indipendenti su registrazione, gestione dell'input serializzato, riattivazione della sessione, migrazione dei dati e hardening dei gadget.

L'hardening terminale richiede che l'oggetto risolto implementi il contratto provider atteso:

La stringa system controllata dall'attaccante viene quindi rifiutata. Il controllo diretto in questo repository bypassa il vettore HTTP e verifica che questa difesa terminale da sola lasci il suo marker assente.

Verifica di una distribuzione reale

Un risultato PoC negativo da solo non dimostra che un sito è patchato. Un WAF, routing diverso, registrazione disabilitata, modulo legacy mancante, configurazione della sessione o funzioni di comando PHP disabilitate possono tutti impedire il marker su un codebase ancora vulnerabile.

Procedura di validazione consigliata:

1. Registra la versione GiveWP distribuita e la revisione del sorgente.
2. Esegui un backup o uno snapshot del sito WordPress e del database.
3. Ripristina quello snapshot in un ambiente di staging isolato.
4. Disabilita l'accesso di rete in uscita non necessario.
5. Esegui questo verificatore solo-marker contro il clone.
6. Aggiorna GiveWP all'ultima release supportata, con 4.16.7.2 come release minima contenente i fix testati.
7. Ripeti il test identico e richiedi l'assenza del marker.
8. Verifica indipendentemente la versione del plugin installato e il sorgente patchato.

Controllo versione:

Rimedio e revisione dell'incidente

Aggiorna GiveWP all'ultima versione supportata. Dopo l'aggiornamento:

• Svuota le cache opcode PHP dove applicabile.
• Conferma che nessuna copia precedente di GiveWP rimanga attiva o accessibile via web.
• Rivedi account WordPress o donatori inattesi.
• Cerca nei metadati utente e nelle sessioni GiveWP grafi serializzati TCPDF, Session Symfony o loadedProviders.
• Correla registrazione, modifiche del profilo, richieste di donazione e successive risposte HTTP 500 dalla stessa sessione.
• Indaga su processi figlio del web-server o modifiche al filesystem inattese.

Se un'installazione vulnerabile esposta a internet contiene artefatti di iniezione di oggetti, trattala come una potenziale compromissione piuttosto che limitarti ad aggiornare il plugin.

Struttura del repository

Non committato:

Limiti di validazione

Lo standard di prova è deliberatamente rigoroso: solo un marker di comando osservabile attraverso la catena stock non modificata viene etichettato come RCE. Accettazione HTTP, serializzazione, eccezioni e hit del rilevatore sono evidenze intermedie.