Un lecteur qui gère une quarantaine d'installs clients m'a écrit hier : le nouvel avis WordPress liste tellement de préconditions qu'il était tenté de le classer dans la case plus tard. Je comprends le réflexe. Je pense aussi qu'il regarde du mauvais côté. Passe à 7.1.2 aujourd'hui, cette partie prend quelques minutes. La leçon qui mérite qu'on la garde est plus large : ce bug n'est devenu dangereux qu'à cause de fichiers et de flags que la plupart d'entre nous n'ont jamais choisis et n'ont jamais audités une seule fois.

php.ini
; Mitigation while you roll out 7.1.2; updating WordPress is the real fix.
register_argc_argv = Off

D'abord la version sèche. WordPress 7.1.2 est sorti le 22 septembre 2026 et referme CVE-2026-87902, noté 9.2 Critique sous CVSS 4.0. La faille se loge dans la résolution de template autour de get_page_template() : dans les bonnes conditions, un visiteur non authentifié peut pousser WordPress à inclure un fichier PHP local situé hors du répertoire du thème, du CWE-98 pur manuel. L'avis porte la référence GHSA-7hp8-65ch-5whp, et le correctif a été rétroporté jusqu'à la branche 4.7, donc il y a une release de sécurité qui attend pour à peu près chaque install dont tu as honte.

Maintenant la partie intéressante, les conditions. Pour que l'inclusion malveillante soit atteignable, le thème actif doit avoir un répertoire de premier niveau dont le nom commence par page-, quelque chose comme page-templates. L'avis cite Twenty Twelve, Twenty Fourteen, Neve, Hestia et Sydney comme thèmes où cette structure existe, ce qui n'est pas une accusation, juste de la géographie. Et pour transformer une inclusion de fichier en exécution de code, l'attaquant a besoin qu'un fichier PHP utile traîne déjà sur le disque. L'exemple de l'avis est pearcmd.php, qui devient un gadget dès que register_argc_argv est activé, une combinaison qu'il signale explicitement pour l'image Docker PHP officielle et pour les configs cPanel par défaut tournant sous des versions de PHP inférieures à 8.5.

Relis cette liste. Il y a un utilitaire en ligne de commande PEAR livré dans l'image de base, que tu aies tapé pear cette décennie ou pas. Il y a register_argc_argv, un switch ini hérité de l'ère CGI. Même la condition du thème n'est qu'une habitude de nommage de répertoire plus vieille que l'éditeur de blocs. Aucun de ces éléments n'est un bug en soi. Ensemble, ils forment la piste de décollage qui permet à un dérapage de résolution de template de s'envoler en exécution de code à distance. WordPress a écrit la ligne vulnérable, mais la stack autour a fourni les complices.

Le contre-argument honnête, c'est que cet empilement est précisément ce qui a protégé la plupart des sites. Trois conditions doivent s'aligner, donc une install obsolète n'est pas automatiquement à une requête forgée d'une prise de contrôle, et l'avis le dit lui-même. C'est vrai, et je suis content que la couverture soit restée globalement calme là-dessus. Voici pourquoi je ne me détends toujours pas : chacune de ces conditions est facile à sonder à distance et à grande échelle. La structure du thème fuit par les URLs d'assets, les empreintes d'hébergement trahissent cPanel, et les attaquants scriptent ces vérifications en un après-midi pendant que les défenseurs se disent que les astres ne s'aligneront sans doute pas chez eux. Des préconditions étroites se lisent bien dans un avis et très mal dans un rapport d'incident.

Donc l'ordre des opérations est ennuyeux exprès. Mets à jour d'abord, depuis le dashboard ou avec la release correspondant à la branche que tu fais tourner. Ensuite, tant que tu es sur la machine, vérifie register_argc_argv et désactive-le sauf si tu as une vraie raison de le garder, parce que ça seul casse le maillon pearcmd.php dans la chaîne. Et si un site est resté exposé sur une version affectée avec un thème et une config d'hébergement qui matchent, passe dix minutes à greper le journal d'accès pour des requêtes de template bizarres et à comparer wp-content avec une copie saine avant de fermer le ticket.

Le correctif de fond, c'est de traiter ton image de base comme une dépendance. Que l'avis trace une ligne à PHP 8.5 est un indice que les nouveaux réglages de plateforme par défaut ferment déjà une partie de ce chemin. Si tu construis sur l'image Docker officielle, ça te coûte deux lignes dans l'étape de production pour retirer l'outillage PEAR que tu n'invoques jamais. Les gens de Go aiment rappeler que leur artefact de déploiement est un binaire unique sans rien d'autre dedans, et d'accord, celle-là ils l'ont méritée, mais rien n'empêche un conteneur PHP d'être presque aussi dépouillé. On doit juste accepter qu'un logiciel qu'on n'a jamais installé volontairement compte quand même comme surface d'attaque.

Ce qui m'amène à la question à laquelle je veux vraiment une réponse sous cette colonne. Quand tu audites une machine ou une image de production, est-ce que tu pars à la chasse aux restes exécutables comme pearcmd.php, ou est-ce que ta revue s'arrête à ton propre code et à ton composer.lock ? Et si la réponse honnête est la seconde, qu'est-ce qu'il faudrait, de l'outillage, du temps ou une frousse comme celle-ci, pour déplacer cette ligne ?