Résumé

WordPress résout un modèle de Page via une chaîne qui ne prouve jamais que le fichier sélectionné reste à l'intérieur d'une racine de thème :

1. pagename et page_id sont des variables de requête publiques que WP::parse_request() accepte depuis un corps POST anonyme.
2. Une traversée doublement encodée dans pagename survit à l'assainissement précoce de la requête sous forme d'octets %xx échappés (wp_basename() ne peut pas voir %2f comme un séparateur, et sanitize_title_with_dashes() conserve délibérément les octets valides).
3. Un page_id valide sélectionne alors une vraie Page publiée, tandis que le pagename malveillant reste dans l'objet de requête.
4. get_page_template() appelle ensuite urldecode() sur cette valeur et ajoute un candidat tel que page-templates/../../../../../../../usr/local/lib/php/pearcmd.php à la hiérarchie des modèles.
5. locate_template() et le chargeur de modèle final ne vérifient que l'existence, la lisibilité et le suffixe .php/.html — jamais que le chemin canonique se trouve encore dans une racine de thème autorisée — puis l'include.

Il s'agit d'une primitive d'inclusion locale de fichier distante non authentifiée dans WordPress Core. Sur le runtime officiel testé (wordpress:php8.3-apache, qui embarque PEAR et ne charge aucun php.ini, donc register_argc_argv est On), l'inclusion a été enchaînée via le pearcmd.php de PEAR : une première requête anonyme fait écrire par config-create du PHP contrôlé par l'attaquant dans /tmp, une seconde requête anonyme inclut ce fichier et l'exécute en tant que www-data.

Le confinement de chemin manquant dans Core est la vulnérabilité. PEAR n'est qu'une route dépendante de l'environnement de l'inclusion vers l'exécution de code — ce n'est pas une dépendance de WordPress et il n'est pas présent ou utilisable dans tous les déploiements.

Cause racine

Emplacements source vérifiés (WordPress 7.0.2) :

Préconditions

La primitive d'inclusion autonome nécessite :

L'étape PEAR démontrée nécessite en plus un pearcmd.php lisible (ainsi que ses dépendances), register_argc_argv=On pour le SAPI web, et un répertoire de sortie inscriptible. Les fichiers php.ini de production définissent register_argc_argv=Off ; l'image testée ne charge aucun php.ini, donc la valeur par défaut compilée (On) s'appliquait. C'est une limite importante sur la prévalence de la chaîne d'exécution de code démontrée.

Les thèmes fournis Twenty Twenty-Three/Four/Five n'embarquent aucun répertoire page-* de premier niveau, donc le lab standard nécessite la fixture décrite ci-dessous. Les thèmes personnalisés peuvent légitimement utiliser une disposition page-templates/ (documentation WordPress).

L'avis consigne où ces conditions se produisent dans les logiciels livrés : la condition de thème est remplie par les thèmes hérités Twenty Twelve et Twenty Fourteen et par des thèmes tiers tels que Neve, Hestia et Sydney, tandis que la transition PEAR s'applique à l'image Docker PHP officielle et aux configurations cPanel par défaut exécutant PHP antérieur à 8.5. (Twenty Twelve et Twenty Fourteen embarquent tous deux un répertoire page-templates/ de premier niveau ; les autres affirmations sont celles de l'avis.) Ce dépôt ne mesure pas la fréquence d'application de la chaîne complète.

Démarrage rapide

cve-2026-87902.py nécessite Python 3.6+ (bibliothèque standard uniquement) et atteint le lab à http://127.0.0.1:8091 par défaut. Sortie attendue :

Le code de sortie est 0 en cas de succès et 1 sinon, donc le PoC fonctionne aussi comme vérification de régression/détection.

Démontage : docker compose down -v.

Résultats vérifiés

Exécuté le 2026-09-22 contre ce lab (Docker 29.4, OrbStack, Apple silicon) :

L'artefact de preuve est /flag, détenu par root et lisible par tous (root:root, mode 0444) à l'intérieur du conteneur. Il prouve l'exécution de PHP et l'accès au fichier en tant que compte du serveur web ; ce n'est pas une cible d'élévation de privilèges.

Comment la chaîne fonctionne

Deux POST anonymes. Les valeurs de routage WordPress voyagent dans le corps du formulaire, les arguments PEAR dans la chaîne de requête brute (PHP découpe la chaîne de requête brute sur le caractère littéral + en argv et ne décode pas individuellement les arguments en URL) :

Étape 1 — inclure pearcmd.php et écrire la charge utile :

Étape 2 — inclure le fichier généré et exécuter son PHP :

Détails importants :

• Deux couches d'encodage. Le corps est décodé une fois par PHP en templates%2f%2e%2e%2f... ; l'assainisseur conserve ces octets, et seul l'urldecode() tardif de get_page_template() les transforme en / et ...
• Préfixe page-. WordPress préfixe la valeur par page-, donc le répertoire de fixture page-templates/ correspond au segment initial templates.
• Suffixe .php forcé. Le candidat est page-<decoded>.php, c'est pourquoi la cible est donnée sans suffixe (.../pearcmd, /tmp/wp-pear-rce-flag).
• POST, pas GET. redirect_canonical() ignore les requêtes non-GET/HEAD, et le corps du formulaire permet à la chaîne de requête de ne porter que les arguments PEAR.
• Charge utile sans guillemets. wp_magic_quotes() s'exécute aussi sur $_SERVER, donc l'argv construit par le serveur est échappé et PEAR normalise ensuite les barres obliques inverses. La charge utile vérifiée utilise chr() et ne contient aucun caractère de guillemet. (Elle se réduit à <?=file_get_contents('/flag')?>.)
• Chemin racine de config-create. PEAR rejette une racine relative (Root directory must be an absolute path beginning with "/"), donc la charge utile est injectée comme chemin racine lui-même.
• Profondeur. cve-2026-87902.py parcourt les segments .. jusqu'à ce que la traversée atteigne la cible (7 pour la disposition de ce lab, --depth pour la fixer).

Lab

lab/up.sh effectue trois étapes et peut être réexécuté sans risque :

1. docker compose up -d --build --wait — wordpress:7.0.2-php8.3-apache épinglé plus mysql:8.4, port 127.0.0.1:8091 (loopback uniquement).
2. Exécute l'installateur WordPress (admin / adminadmin) si le site n'est pas encore installé.
3. Crée la fixture à l'intérieur du thème actif et l'affiche : wp-content/themes/twentytwentyfive/page-templates/, root:root, mode 0755, vide.

L'image du lab ajoute explicitement register_argc_argv=On (lab/Dockerfile) au lieu de se fier à la valeur par défaut compilée, et intègre /flag (root:root, mode 0444, contenu CVE-2026-87902-POC-OK).

Le tag roulant wordpress:php8.3-apache n'est pas utilisable pour ce lab : le bug est corrigé dans 7.1.2 et un tag non épinglé transforme silencieusement le lab en version corrigée.

Contrôles négatifs et limitations

Contrôles vérifiés ou documentés :

• Aucun répertoire page-* de premier niveau dans le thème → le préfixe fixe ne peut pas être supprimé et la traversée ne démarre jamais (vérifié : fixture supprimée → aucun marqueur).
• register_argc_argv=Off → pas d'écrivain PEAR, mais la primitive d'inclusion subsiste.
• PEAR ou ses dépendances absents → pas d'écrivain.
• Mauvais nombre de segments .. → cible non atteinte (vérifié : les profondeurs 1-6 et 8-12 ne produisent aucun marqueur dans le lab).
• Un modèle de page personnalisé assigné à la Page → ordonné avant le candidat malveillant et gagne.
• Un fichier sans suffixe (par ex. /flag) ne peut pas être lu directement — le candidat reçoit .php en suffixe.
• Un WAF/CDN/proxy inverse qui rejette les octets bruts <, >, = dans la cible de la requête casse le canal d'arguments PEAR (spécifique au déploiement).
• Le confinement open_basedir/MAC ou un répertoire de sortie non inscriptible casse la chaîne ; noexec sur /tmp non (PHP lit et interprète le fichier).

Ce PoC reproduit une configuration vérifiée. Il ne prétend pas que chaque installation WordPress est exploitable, et il ne mesure pas la prévalence.

Remédiation

• Mettre à niveau vers WordPress 7.1.2 ou plus récent (ou vers le backport de votre branche).
• Défense en profondeur pour la gestion des modèles : après décodage, rejeter les candidats de traversée et absolus (par ex. validate_file()), et avant d'inclure un modèle localisé, comparer realpath() du candidat et de la racine du thème avec un séparateur de répertoire final.
• Atténuations opérateur : définir register_argc_argv=Off pour les SAPI web, supprimer les points d'entrée PEAR inutilisés lisibles par le web des images de production, auditer les thèmes enfant et parent pour les répertoires page-* de premier niveau, et restreindre l'accès en écriture pour le compte PHP.

Fichiers

Chronologie de divulgation

Le rapport a été accepté comme une découverte de sécurité valide après révision de sa classification initiale ; la correspondance ne date pas cette acceptation.

Avertissement

Ce dépôt est publié à des fins défensives et de recherche. Utilisez-le uniquement contre des systèmes que vous possédez ou que vous êtes explicitement autorisé à tester. Le lab est lié à 127.0.0.1 et ne doit pas être exposé à des réseaux non fiables.

Licence

MIT — voir LICENSE. Les métadonnées de citation se trouvent dans CITATION.cff :

Ressl, Robert (2026). CVE-2026-87902 PoC: unauthenticated path traversal in WordPress page-template resolution (v1.0.0). https://ressl.ch

Le rapport de vulnérabilité et ce PoC ont été préparés avec l'aide de l'IA pour l'organisation et la revue de cohérence ; le chercheur est responsable des affirmations techniques.