Le PoC fourni est volontairement contraint :

• Il exécute uniquement touch /tmp/CVE-2026-82222-RCE-GETBAG.
• Il n'offre aucune option de commande arbitraire.
• Il ne crée aucun shell, callback, persistance ou élévation de privilèges.
• Il refuse les cibles non-loopback sauf si l'opérateur fournit l'indicateur explicite --allow-authorized-non-loopback.
• Docker publie WordPress uniquement sur 127.0.0.1.
• Le nom du projet Compose est dérivé du chemin de checkout afin qu'un clone ne puisse pas démonter les conteneurs ou volumes d'un autre clone.
• Le laboratoire utilise la source officielle du plugin pristine ; il n'instrumente ni ne patche la cible vulnérable.

Le test HTTP crée un utilisateur donateur jetable, des métadonnées et des lignes de session GiveWP. Utilisez la commande de réinitialisation incluse après le test.

Démarrage rapide

Prérequis :

• Docker avec Compose v2
• Python 3.10 ou ultérieur
• curl
• unzip
• sha256sum ou shasum
• Accès réseau à downloads.wordpress.org pour les archives officielles du plugin

Exécutez la matrice complète vulnérable/patché :

La commande :

1. Télécharge GiveWP 4.16.5.1 et 4.16.7.2 depuis WordPress.org.
2. Vérifie les deux hachages SHA-256.
3. Construit un laboratoire WordPress 6.6.2/PHP 8.1 frais en loopback uniquement avec l'enregistrement WordPress normal explicitement désactivé.
4. Teste la version pristine 4.16.5.1 et exige la création du marqueur par l'utilisateur web.
5. Construit un second laboratoire frais avec la version pristine 4.16.7.2.
6. Exige que le marqueur HTTP reste absent.
7. Contourne l'entrée dans un contrôle direct et confirme que le terminal ProviderForwarder patché rejette également l'appelable chaîne.

Le laboratoire patché reste en cours d'exécution à la fin. Supprimez-le avec :

Pour utiliser un autre port loopback :

Preuves attendues

Le contrôle vulnérable doit se terminer avec des preuves terminales concrètes :

Le contrôle patché doit afficher :

Un HTTP 500, une charge utile stockée, une exception ou un déclenchement de détecteur sans le marqueur n'est pas accepté comme preuve de RCE.

Cycle de vie manuel du laboratoire

Démarrez et testez la version vulnérable :

Démarrez et testez la version patchée :

Inspectez l'état actuel :

Supprimez les conteneurs, volumes, utilisateurs de test, sessions et état du marqueur :

Les ZIP de plugins en cache et les ressources extraites sont conservés pour des réexécutions plus rapides. Supprimez également ces ressources générées exactes avec :

Versions affectées et testées

L'avis public identifie les versions jusqu'à 4.16.7.1 comme affectées. Ce dépôt prouve directement uniquement les deux versions de sa matrice de tests positifs/négatifs.

Références :

• Avis Patchstack
• CVE-2026-82222
• Commit de durcissement GiveWP
• Page officielle du plugin GiveWP

Cause racine

L'exploit combine plusieurs comportements :

1. GiveWP 4.16.5.1 expose une action d'enregistrement qui crée et authentifie un donateur à faibles privilèges même lorsque l'enregistrement WordPress normal est désactivé.
2. Cet utilisateur peut persister des données sérialisées dans ses propres métadonnées de nom.
3. Give\Helpers\Utils::maybeSafeUnserialize() utilise allowed_classes => false, produisant __PHP_Incomplete_Class, mais une sérialisation ultérieure préserve les noms de classes et propriétés d'origine.
4. Le graphe est stocké dans une session d'achat GiveWP.
5. Un maybe_unserialize() non restreint ultérieur ravive les classes fournies.
6. La destruction automatique entre dans une chaîne POP complète jusqu'à system().

Quatre barres obliques inversées de namespace littérales sont requises dans le vecteur HTTP. Les deux passes de suppression effectives les réduisent 4 -> 2 -> 1. La charge utile est sans NUL, et PHP 8.1.30 a été vérifié pour hydrater le nom sérialisé simple pour la propriété privée Session::$attributeName.

Chaîne POP complète

Graphe contrôlé par l'attaquant :

La transition cachée critique est la répartition implicite IteratorAggregate de PHP. TCPDF::$imagekeys est non typé, donc l'assignation d'une Session Symfony fait que foreach invoque Session::getIterator().

La commande marqueur s'exécute avant que Symfony n'applique le type de retour getAttributeBag(): AttributeBagInterface. Le TypeError résultant et le HTTP 500 sont des effets post-sink.

Ce que les tentatives précédentes ont manqué

Le graphe candidat rejeté utilisait :

Ce graphe ne peut pas fonctionner. TCPDF::_destroy() ne fait que désassigner objcopy ; PHP ne route pas la destruction automatique via __call('__destruct', ...).

L'opération manquante était :

La revue précédente suivait les destructeurs et les appels de méthodes explicites mais n'inspectait pas récursivement le protocole d'objets implicite déclenché par foreach. La Session Symfony fournit le pont manquant :

• foreach invoque getIterator().
• getIterator() atteint getBag($attributeName).
• Le storage contrôlé par l'attaquant est un DonationFactory.
• Le getBag non défini invoque ProviderForwarder::__call().
• loadedProviders['getBag'] = 'system' sélectionne l'appelable.
• attributeName fournit l'argument de commande.

Preuves source

Emplacements pertinents GiveWP 4.16.5.1 :

Hachages des versions officielles :

Le laboratoire ré-extrait chaque plugin depuis son ZIP vérifié avant chaque démarrage frais, le copie dans WordPress sans modification, et compare octet par octet l'arborescence complète des fichiers du plugin déployé avec la source vérifiée. Les trois images de base Docker officielles sont également épinglées à leurs digests de manifeste multi-architecture.

Pourquoi 4.16.7.2 bloque la chaîne

GiveWP 4.16.7.2 ajoute des défenses indépendantes sur l'enregistrement, le traitement des entrées sérialisées, le ravivement de session, la migration de données et le durcissement des gadgets.

Le durcissement terminal exige que l'objet résolu implémente le contrat de fournisseur attendu :

La chaîne system contrôlée par l'attaquant est donc rejetée. Le contrôle direct dans ce dépôt contourne le vecteur HTTP et vérifie que cette défense terminale seule laisse son marqueur absent.

Vérification d'un déploiement réel

Un résultat PoC négatif en soi ne prouve pas qu'un site est patché. Un WAF, un routage différent, un enregistrement désactivé, un formulaire hérité manquant, une configuration de session ou des fonctions de commande PHP désactivées peuvent tous empêcher le marqueur sur un codebase toujours vulnérable.

Procédure de validation préférée :

1. Enregistrez la version GiveWP déployée et la révision source.
2. Sauvegardez ou faites un instantané du site WordPress et de la base de données.
3. Restaurez cet instantané dans un environnement de staging isolé.
4. Désactivez l'accès réseau sortant inutile.
5. Exécutez ce vérificateur à marqueur uniquement contre le clone.
6. Mettez à jour GiveWP vers la dernière version prise en charge, avec 4.16.7.2 comme version minimale contenant les correctifs testés.
7. Répétez le test identique et exigez l'absence du marqueur.
8. Vérifiez indépendamment la version du plugin installé et la source patchée.

Vérification de version :

Remédiation et revue d'incident

Mettez à jour GiveWP vers la dernière version prise en charge. Après la mise à jour :

• Videz les caches d'opcode PHP le cas échéant.
• Confirmez qu'aucune copie plus ancienne de GiveWP ne reste active ou accessible via le web.
• Examinez les comptes WordPress ou donateurs inattendus.
• Recherchez dans les métadonnées utilisateur et les sessions GiveWP des graphes sérialisés TCPDF, Session Symfony ou loadedProviders.
• Corrélez l'enregistrement, les modifications de profil, les demandes de don et les réponses HTTP 500 ultérieures de la même session.
• Enquêtez sur les processus enfants du serveur web ou les modifications du système de fichiers inattendus.

Si une installation vulnérable exposée à Internet contient des artefacts d'injection d'objets, traitez-la comme une compromission potentielle plutôt que de simplement mettre à jour le plugin.

Structure du dépôt

Non commité :

Limites de validation

La norme de preuve est délibérément stricte : seul un marqueur de commande observable via la chaîne stock non modifiée est étiqueté RCE. L'acceptation HTTP, la sérialisation, les exceptions et les déclenchements de détecteurs sont des preuves intermédiaires.