En quoi consiste la vulnérabilité

Le gestionnaire non authentifié send_to_site (includes/customclass/class-wpvivid-send-to-site.php) déchiffre un blob fourni par l'attaquant et écrit le contenu de $params['data'] dans wp-content/wpvividbackups/<nom contrôlé par l'attaquant> — sans authentification, sans nonce et sans assainissement du chemin sur name.

La protection prévue est RSA : le message doit être chiffré avec une clé de session aléatoire, elle-même chiffrée RSA avec la clé du site. La faille se trouve dans WPvivid_crypt::decrypt_message (includes/class-wpvivid-crypt.php) :

La méthode Crypt_RSA::decrypt() de phpseclib retourne false lorsque le blob de clé fourni ne peut pas être déchiffré (par exemple, openssl_private_decrypt() échoue), et le plugin n'interrompt pas l'exécution. false est ensuite transmis à Crypt_Rijndael::setKey(), où strlen(false) → 0 → la clé est complétée avec 16 octets nuls (AES-128, mode CBC, IV nul). Un attaquant peut donc « chiffrer » la charge utile avec une clé nulle entièrement prévisible — aucune connaissance de la clé réelle du site n'est requise.

La charge utile est au format JSON :

name est concaténé dans le chemin sans assainissement (str_replace('wpvivid','wpvivid_temp', $name) ne réécrit que la sous-chaîne « wpvivid »), donc ../../ permet de sortir de wp-content/wpvividbackups/ vers la racine web. Lorsque file_size/md5 correspondent, le fichier temporaire est renommé avec le nom choisi par l'attaquant → PHP accessible publiquement → RCE.

Le correctif (changeset 3448386) interrompt l'exécution lorsque l'étape RSA échoue :

Prérequis

Cible :

• WPvivid Backup & Migration ≤ 0.9.123
• L'option wpvivid_api_token doit exister et ne pas être expirée — créée lorsqu'un administrateur clique sur Générer sous WPvivid → Réglages → Migration automatique (courant sur les sites qui utilisent la fonctionnalité de migration)
• Exécution de fichiers PHP dans la racine web (par défaut sur la plupart des hébergements)

Attaquant :

• Python 3 (bibliothèque standard uniquement)

Utilisation

script.py est entièrement autonome : bibliothèque standard uniquement, aucune importation locale, aucun fichier externe. CLI positionnelle simple :

Codes de sortie : 0 vulnérable, 1 sinon.

Laboratoire

../lab/ contient une cible vulnérable dockerisée (WordPress 6.8 + source WPvivid 0.9.123 depuis plugins/) :

Découverte de cibles

Source vérifiée et fonctionnelle (testée en conditions réelles, sans compte requis) :

• urlscan.io — ouvrez ceci dans un navigateur : https://urlscan.io/search/#filename:wpvivid-backuprestore ~74 pages indexées référençant le slug du plugin ; parcourez-les et collectez les noms d'hôtes. Chaque URL de résultat commence par le chemin du plugin (/wp-content/plugins/wpvivid-backuprestore/), l'extraction des hôtes est donc facile.

Requêtes testées qui ne produisent PAS de cibles (exclues volontairement) : dorks Google/Bing (inurl: ne renvoie que les pages wordpress.org du plugin lui-même ou un mur anti-bot), DuckDuckGo (idem), Shodan http.html: (HTML tronqué indexé, zéro résultat), Wayback CDX wildcard (vide), PublicWWW (collecte invité bloquée).

Fournissez les hôtes collectés au triage (intégré dans script.py avec --triage), qui vérifie pour chaque site :

1. Version — wp-content/plugins/wpvivid-backuprestore/readme.txt → Stable tag: 0.9.123 (vérification non authentifiée à faible bruit ; les chaînes de requête ?ver= des assets dans le HTML servent de solution de repli)
2. Jeton — POST poubelle wpvivid_action=send_to_site&wpvivid_content=AAAA : réponse JSON (The key is invalid.) = wpvivid_api_token existe ; vide = pas de jeton / plugin inactif / WAF a bloqué la sonde

Seuls les sites qui sont <= 0.9.123 et avec un jeton actif sont écrits dans in-scope.txt, puis :

Survie réseau

Techniques portées depuis un téléverseur de 2025 à longue durée de vie qui a continué de fonctionner dans la nature (même auteur) :

• Déguisement AJAX sur le POST de téléversement : X-Requested-With: XMLHttpRequest, Accept: application/json, */*;q=0.1, Referer de même origine, UA de navigateur
• Les GET de suivi du shell portent un Referer de même origine
• Mode par lots multithread (--threads N) avec des délais d'attente courts par requête
• success.txt / failed.txt écrits en mode par lots, seuls les shells vérifiés sont enregistrés comme succès (comme le fichier success de l'original)
• Noms de fichiers aléatoires à 12 hexadécimaux et noms de paramètres de shell aléatoires par téléversement
• --encode / --multipart pour l'évasion sur la forme des requêtes

Vérifié contre un mod_security live (OWASP CRS paranoia 1) en laboratoire

../lab/waf/ ajoute un proxy inverse owasp/modsecurity-crs:apache devant le WordPress vulnérable (WAF sur :8092, cible brute sur :8093). Comportement mesuré :

Le téléversement chiffré est invisible pour l'inspection de contenu CRS (même propriété de survie que l'AJAX à apparence légitime du téléverseur de 2025). La seule surface CRS est le GET de commande de suivi, donc l'outil utilise désormais --command id par défaut et confirme la RCE via le marqueur PWN-OK en GET simple même lorsque le GET de commande est filtré par le WAF (signalé comme vulnerable avec une note). Les WAF sur l'hôte qui signent wpvivid_action=send_to_site (par exemple, le correctif virtuel Wordfence) bloquent toujours le téléversement lui-même au niveau du plugin — aucune astuce sur la forme des requêtes ne contourne ceux-ci.

Références

• https://www.wordfence.com/threat-intel/vulnerabilities/id/e5af0317-ef46-4744-9752-74ce228b5f37
• https://plugins.trac.wordpress.org/changeset/3448386/wpvivid-backuprestore
• https://nvd.nist.gov/vuln/detail/CVE-2026-1357