CVE-2026-87902 en bref — ce qui se passe en ce moment
La faille réside dans la fonction get_page_template(), qui construit le nom du fichier de thème à partir du paramètre pagename de la requête HTTP sans le valider correctement. Un attaquant non authentifié peut injecter des séquences de traversée de répertoire doublement encodées pour forcer WordPress à inclure n'importe quel fichier PHP lisible sur le serveur, en dehors des répertoires de thème autorisés.
La faille est qualifiée de LFI conditionnelle vers RCE : l'exécution de code n'est pas garantie sur chaque installation, mais les conditions requises sont très répandues. Patchstack a observé dès les premières heures d'exploitation des payloads qui utilisent pearcmd.php — présent par défaut dans les images Docker officielles et les environnements cPanel avec PHP < 8.5 — pour écrire des fichiers PHP exécutables dans /tmp ou /var/tmp. Le score CVSS 4.0 de 9.2 reflète l'absence totale d'authentification requise et l'impact potentiel sur la confidentialité, l'intégrité et la disponibilité du serveur.
- Inclure un fichier PHP arbitraire lisible hors du répertoire de thème actif via une traversée de chemin dans le paramètre
pagename - Utiliser
pearcmd.php(présent sur cPanel/PHP < 8.5 et images Docker officielles) pour écrire un fichier PHP contrôlé par l'attaquant sur le disque - Déposer un webshell dans
/tmpou/var/tmpsous un nom générique (wp-pear-rce-flag.php,poc87902.php) - Exécuter des commandes shell sur le serveur sans aucun compte WordPress ni intervention d'un utilisateur
- Pivoter vers d'autres sites hébergés sur le même serveur si les permissions le permettent
- Exfiltrer des données de base de données, des clés API ou des fichiers
.envaccessibles en lecture
Vérifier si vos sites sont exposés
La première étape est de connaître la version WordPress de chaque installation. Avec WP-CLI, la commande est directe et s'exécute en quelques secondes, même sur un parc de plusieurs dizaines de sites.
Vérifier la version courante et les mises à jour disponibles :
`wp core version
wp core check-update`Lister toutes les installations WordPress sur un serveur cPanel (si vous gérez plusieurs sites) :
find /home -name 'wp-config.php' -not -path '*/wp-content/*' 2>/dev/nullVérifier la version de chaque installation trouvée :
wp --path=/home/user/public_html core versionIdentifier si le thème actif contient un répertoire commençant par
page-(condition d'exploitation) :ls $(wp --path=/home/user/public_html eval 'echo get_stylesheet_directory();') | grep '^page-'Vérifier si
register_argc_argvest activé (deuxième condition d'exploitation) :php -r 'echo ini_get("register_argc_argv") ? "EXPOSED" : "OK";'Rechercher des traces d'exploitation dans les logs d'accès (pattern caractéristique) :
`grep -E 'pagename=.*\.\..*page_id=' /var/log/nginx/access.log
grep -E 'pagename=.*%2e%2e.*page_id=' /var/log/apache2/access.log`
Une installation est exposée au RCE si elle réunit les trois conditions : version entre 4.7.0 et 7.1.1, thème actif contenant un répertoire page-* à la racine, et register_argc_argv activé. L'LFI seule (sans RCE) est possible dès que les deux premières conditions sont remplies. Les thèmes les plus souvent cités par les chercheurs sont les thèmes par défaut anciens (Twenty Twelve, Twenty Fourteen) et des thèmes tiers populaires comme Neve, Hestia et Sydney.
Sauvegarder avant de patcher
Avant toute mise à jour de WordPress core, une sauvegarde est indispensable. Sur un VPS, la méthode la plus fiable est le snapshot de la VM — elle capture l'état complet du disque en quelques secondes et permet un rollback immédiat en cas de problème de compatibilité avec un plugin. En parallèle, exporter la base de données avec WP-CLI garantit une restauration ciblée sans avoir à remonter le snapshot entier.
Créer un snapshot de la VM depuis le panneau VPS (opération instantanée, rollback en < 2 min) — ou depuis l'API si vous automatisez :
`# Exemple avec l'API Proxmox
pvesh create /nodes/{node}/qemu/{vmid}/snapshot --snapname pre-wp712`Exporter la base de données WordPress avec WP-CLI :
wp db export backup-pre-712.sql --add-drop-tableVérifier l'intégrité du dump :
wp db checkCopier le dump hors du serveur (espace de stockage distant ou local) :
rsync -avz user@serveur:/home/user/public_html/backup-pre-712.sql ./
Patcher WordPress 7.1.2 — les étapes
Sur un VPS avec accès root, la mise à jour WordPress s'effectue via WP-CLI sans intervention de l'hébergeur. Le processus complet — sauvegarde comprise — prend moins de trois minutes. WordPress 7.1.2 a été publié le 22 septembre 2026 ; les correctifs ont également été rétroportés sur toutes les branches maintenues jusqu'à la version 4.7.
Mettre WordPress en mode maintenance pour éviter toute requête pendant la mise à jour :
wp maintenance-mode activateMettre à jour le core WordPress vers 7.1.2 :
wp core updateVérifier que la mise à jour s'est bien appliquée :
`wp core version
# Doit retourner : 7.1.2`Mettre à jour la base de données si nécessaire :
wp core update-dbVider le cache d'objets et les caches applicatifs :
wp cache flushDésactiver le mode maintenance :
wp maintenance-mode deactivateVérifier l'absence d'erreurs dans les logs et tester une page clé du site :
`wp eval 'echo get_permalink(get_option("page_on_front"));'
curl -sI https://votre-site.com/ | grep HTTP`Si plusieurs sites sont hébergés, boucler sur chaque installation :
`for dir in $(find /home -name 'wp-config.php' -not -path '*/wp-content/*' -exec dirname {} \;); do
echo "=== $dir ==="
wp --path="$dir" core update
done`
Pourquoi le mutualisé vous expose plus longtemps
Sur un hébergement mutualisé, les mises à jour automatiques de WordPress core sont gérées par l'hébergeur ou par le panneau de contrôle (cPanel, Plesk). La fenêtre entre la publication du correctif et son application effective dépend du planning de l'hébergeur, de la charge de ses serveurs et de ses propres tests de non-régression. Dans le cas de CVE-2026-87902, l'exploitation active a démarré moins de cinq heures après la publication du patch — un délai bien inférieur au cycle de mise à jour de la plupart des mutualisés.
Faites défiler le tableau
| Critère | Mutualisé (cPanel/Plesk) | VPS root ServOrbit |
|---|---|---|
| Délai de patch après publication | Mutualisé : 12 à 72 heures selon l'hébergeur | VPS root : < 3 minutes avec WP-CLI |
| Accès aux logs d'accès | Mutualisé : limité ou inexistant selon l'offre | VPS root : accès complet à /var/log en temps réel |
| Contrôle de `register_argc_argv` | Mutualisé : imposé par l'hébergeur, souvent activé | VPS root : désactivable via `php.ini` en 30 secondes |
| Isolation des sites | Mutualisé : même serveur que d'autres clients | VPS root : environnement dédié, pas de voisinage |
| Sauvegarde avant patch | Mutualisé : snapshot non disponible ou payant | VPS root : snapshot instantané via l'API |
L'argument « mon hébergeur met à jour automatiquement » ne tient plus face à une exploitation qui démarre à J+0 en moins de cinq heures. Sur CVE-2026-87902, les premières requêtes malveillantes ont été enregistrées le 22 septembre 2026 à 17 h 44 UTC — soit avant que la plupart des mutualisés aient eu le temps de planifier et tester leur déploiement.
Configuration post-patch recommandée : (1) Désactiver XML-RPC si vous n'utilisez pas d'application mobile WordPress ni Jetpack :
`# Dans wp-config.php
add_filter('xmlrpc_enabled', '__return_false');`
(2) Forcer les mises à jour automatiques du core pour les futures releases de sécurité :
`# Dans wp-config.php
define('WP_AUTO_UPDATE_CORE', 'minor');`
(3) Désactiver register_argc_argv dans php.ini pour supprimer le vecteur RCE via pearcmd.php :register_argc_argv = Off
(4) Ajouter une règle WAF pour bloquer les patterns de traversée dans le paramètre pagename en attendant la propagation du patch sur les installations en retard.
Dépannage — erreurs courantes après le patch
La mise à jour du core WordPress est généralement sans friction, mais certains environnements présentent des problèmes prévisibles. Voici les cas les plus fréquents et leur résolution.
- Erreur de connexion à la base de données après mise à jour : lancez
wp core update-dbsi vous ne l'avez pas fait — certaines migrations de schéma ne s'appliquent pas automatiquement. - Écran blanc ou erreur 500 : vérifiez les logs PHP (
/var/log/php8.x-fpm.log) et désactivez temporairement tous les plugins pour isoler un conflit de compatibilité avec la version 7.1.2 :wp plugin deactivate --all. - Permission refusée sur
wp-content/: WP-CLI doit être exécuté avec l'utilisateur propriétaire des fichiers. Sur cPanel :su - cpanelusername -c 'wp core update'. - Mise à jour impossible, message « Filesystem not available » : configurez la méthode d'accès direct dans
wp-config.php:define('FS_METHOD', 'direct');— valide uniquement sur un VPS où vous êtes propriétaire des fichiers. - Thème enfant qui casse après le patch : si votre thème enfant hérite d'un thème avec un répertoire
page-*, vérifiez la compatibilité du parent avec 7.1.2 sur le dépôt GitHub ou WordPress.org du thème. - Cache d'objet périmé (Redis/Memcached) : après
wp cache flush, redémarrez le service de cache si les erreurs persistent :systemctl restart redisousystemctl restart memcached.
De WordPress vers une architecture plus robuste
CVE-2026-87902 illustre une réalité structurelle : WordPress core est une surface d'attaque large, et chaque faille critique repose la question du contrôle de l'environnement d'exécution. Un VPS dédié n'élimine pas les vulnérabilités, mais il réduit la fenêtre d'exposition à quelques minutes, permet d'auditer l'environnement (logs, PHP config, isolation des processus) et de répondre précisément à chaque vecteur d'attaque documenté.
Pour les agences et les développeurs qui gèrent un parc de sites WordPress, la consolidation sur un VPS avec WP-CLI installé et des scripts de mise à jour automatisée transforme une urgence sécurité en procédure de routine. Le coût opérationnel d'un VPS est compensé par l'élimination du délai hébergeur — qui, comme le montre cette CVE, peut s'avérer décisif.
