Votre WordPress tourne-t-il sur un PHP corrigé ?

Le 21 octobre 2026, le projet PHP a publié quatre versions de sécurité : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent CVE-2026-109618 et CVE-2026-109619, deux failles critiques notées 9,2 en CVSS v4.0. Sur une installation encore vulnérable, une requête sans compte peut faire exécuter du code par le moteur. Mettre WordPress à jour ne change pas ce moteur.

WordPress est écrit en PHP. Le correctif est dans PHP. Passer le site en 7.1.3, désactiver une extension ou vider le cache de page laisse le même binaire répondre aux requêtes. L’avis est sur php.net. La CISA, alerte du 21 octobre révisée le 23, demande le correctif immédiat et indique ne pas avoir observé, à cette date, d’exploitation réussie. Le surnom public qu’elle retient est php2shell.

Ce qui est exposé

Toute installation qui répond sur le web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed. PHP juge le risque le plus élevé pour mod_php : une démonstration a montré qu’une requête non authentifiée peut déclencher la faille avant le code de l’application. Un pare-feu applicatif peut bloquer des signatures connues. PHP et la CISA le décrivent comme une couche d’attente, pas comme le correctif.

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) porte sur un manque de mémoire. PHP peut être interrompu alors que les données internes de la requête ne sont qu’à moitié initialisées. Le nettoyage qui suit peut les traiter comme si elles étaient valides.

CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) porte sur un état global périmé. Un worker peut garder une référence vers une zone mémoire déjà libérée. La requête suivante, servie par le même worker, peut lire cet état avant que l’initialisation normale ne le remette à zéro.

Les deux chemins mènent à une exécution de code à distance, sans authentification. PHP est explicite : aucun contournement n’est complet.

Le numéro qui compte

Pour un binaire publié par php.net, « PHP 8.3 » ne dit rien. Le seuil est le triplet complet :

• PHP 8.5 est vulnérable jusqu’à 8.5.11 et corrigé à partir de 8.5.12 ;
• PHP 8.4 est vulnérable jusqu’à 8.4.26 et corrigé à partir de 8.4.27 ;
• PHP 8.3 est vulnérable jusqu’à 8.3.35 et corrigé à partir de 8.3.36 ;
• PHP 8.2 est vulnérable jusqu’à 8.2.34 et corrigé à partir de 8.2.35.

PHP 8.2 n’est plus qu’en correctifs de sécurité, et plus aucun après le 31 décembre 2026. La 8.2.35 traite l’urgence d’octobre, pas l’année suivante. PHP 8.1 et les branches plus anciennes n’ont plus de nouvelle version officielle : seulement des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1, destinés à ceux qui compilent. Sur un hébergement, la question est le paquet, pas le triplet affiché.

WordPress 7.1 accepte encore PHP 7.4. La page Requirements recommande PHP 8.3 ou plus. Le handbook hébergement vise, en production, PHP 8.4 ou ultérieur : PHP 8.3 n’est plus qu’en correctifs de sécurité depuis le 31 décembre 2025, et PHP 8.5 est pleinement pris en charge depuis WordPress 6.9. Un cœur compatible avec une vieille branche ne la rend pas sûre.

Santé du site montre le PHP du web

Dans l’administration en français : Outils, Santé du site, onglet Informations, section Serveur, ligne Version de PHP. Cette ligne décrit le PHP qui construit les pages. Ce n’est ni la version de WordPress, ni forcément le php -v d’une session SSH.

Le binaire de la ligne de commande et PHP-FPM cohabitent souvent. WP-CLI s’appuie en général sur le PHP du shell : wp eval peut afficher 8.4.27 pendant que le site répond encore en 8.3.35. Santé du site évite ce décalage, parce qu’elle s’exécute dans la requête web.

Après un changement dans le panneau d’hébergement, les workers déjà lancés gardent l’ancien binaire en mémoire. Vider un cache de page ou un cache d’objets ne les remplace pas. Sur une machine que vous administrez, redémarrez le service qui traite HTTP, php8.3-fpm ou Apache si le site tourne en mod_php, puis rouvrez Santé du site.

Ubuntu 24.04 peut afficher 8.3.6 et être corrigé

Les distributions ont reçu les correctifs avant l’annonce, sans toujours reprendre le numéro amont. L’avis USN-8948-1 du 21 octobre 2026 en donne la liste :

• Ubuntu 24.04 : php8.3-fpm en 8.3.6-0ubuntu0.24.04.13. Santé du site continue d’afficher 8.3.6. Le correctif est dans la révision Ubuntu, pas dans un passage à 8.3.36 ;
• Ubuntu 22.04 : php8.1-fpm en 8.1.2-1ubuntu2.28. Le triplet reste 8.1.2, branche que php.net ne publie plus. Ce paquet contient pourtant les deux correctifs ;
• Ubuntu 26.04 : php8.5-fpm en 8.5.4-0ubuntu1.5 ;
• Ubuntu 26.10 : php8.5-fpm en 8.5.9-0ubuntu2.1.

Lire seulement le triplet php.net produit alors deux erreurs. Juger vulnérable un 8.3.6 dont le paquet est déjà en 8.3.6-0ubuntu0.24.04.13. Ou juger sain tout « PHP 8.3 », y compris un 8.3.6 antérieur à la révision .13. La commande qui tranche est celle du gestionnaire de paquets. Remplacez le nom par php8.1-fpm sur Ubuntu 22.04, ou par php8.5-fpm sur 26.04 et 26.10.

apt-cache policy php8.3-fpm

Debian, ou un hébergeur qui reconstruit PHP, peut créer le même écart. Le dépôt Ondřej Surý aligne au contraire le numéro amont : le 21 octobre 2026, il publiait notamment 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 et 8.4.27-1+ubuntu24.04.1+deb.sury.org+1. Sans SSH, demandez quel paquet sert le vhost et s’il inclut les deux CVE. « Nous sommes en PHP 8.3 » n’est pas une réponse. Une image de conteneur reconstruite ne change rien tant que le service n’est pas redéployé.

Ce qui limite l’exposition en attendant

Les mesures publiées par PHP ferment des chemins confirmés et en laissent d’autres. Elles se posent dans php.ini ou le pool FPM, avant l’exécution du site : ini_set() et .user.ini arrivent trop tard. Sur un mutualisé, elles sont souvent inaccessibles.

Pour CVE-2026-109618, PHP propose memory_limit=-1 via php_admin_value, et post_max_size à 8M sans fichiers, ou 32M s’il en faut, avec upload_max_filesize en dessous. RLIMIT_AS et RLIMIT_DATA sont à éviter : ils peuvent provoquer l’échec d’allocation visé. Un plafond à 8M bloque aussi les médias lourds.

Pour CVE-2026-109619, la demande est session.upload_progress.enabled=0, puis un redémarrage de tous les workers. Sur PHP 8.5, fatal_error_backtraces=0 ne ferme qu’un chemin. Masquer les erreurs avec display_errors ne change rien.

Le 23 octobre, l’avis d’information CVE-2026-115560 décrit un cas peu probable : progression d’envoi active, session.serialize_handler sur php_binary ou php_serialize, puis un ini_set() qui le repasse à php avant session_start(). WordPress ne fait pas ce changement. Les sorties du 21 octobre ne corrigent pas ce CVE. Une progression d’envoi déjà coupée doit le rester jusqu’au prochain correctif de bug.

PHP 8.6.0 RC4 contient les deux correctifs critiques et ne s’utilise pas en production. La candidate suivante est prévue le 5 novembre 2026, la stable le 19 novembre.

L’ordre des contrôles

1. Lire la version de PHP dans Santé du site.
2. Si vous administrez la machine, la comparer au paquet installé, ou à l’image du conteneur qui sert le trafic.
3. Mettre à jour ce moteur. Le cœur, les extensions et le thème ne le font pas.
4. Redémarrer PHP-FPM ou Apache, puis relire Santé du site.
5. Si la branche est 8.1 ou plus ancienne et qu’aucun rétroportage n’est cité, préparer une copie sous PHP 8.4 ou 8.5. WordPress 7.1 les prend en charge. Une extension abandonnée, non.

Une fois la version corrigée en place, la CISA suggère de surveiller un worker PHP qui lance un shell ou télécharge un outil. La version WordPress reste un second numéro, à vérifier à part.

Questions fréquentes

Une extension de sécurité WordPress corrige-t-elle ces failles ?

Non. CVE-2026-109618 et CVE-2026-109619 sont dans le moteur PHP. Aucune extension, aucun thème et aucune mise à jour de WordPress ne remplace le binaire. Un pare-feu peut filtrer des motifs connus. Il ne constitue pas le correctif.

PHP 8.3.35 est-il assez récent ?

Non pour un binaire php.net : le premier 8.3 corrigé est 8.3.36. Les 8.4.26 et 8.5.11 de septembre sont aussi en dessous. Seul un rétroportage, comme 8.3.6-0ubuntu0.24.04.13 sur Ubuntu 24.04, peut être corrigé sans changer le triplet.

Faut-il désactiver la progression d’envoi sur un WordPress ordinaire ?

Tant que le moteur n’est pas corrigé, oui, dans la configuration du serveur, puis en redémarrant les workers. L’avis du 23 octobre vise en plus un changement de sérialiseur pendant la requête, ce que WordPress ne fait pas dans une installation standard. La coupure ne rend pas un vieux PHP sûr. Si elle est déjà en place, PHP demande de la garder jusqu’au prochain correctif de bug.

Le site affiche PHP 8.1.2. Est-il vulnérable ?

Pas d’après le triplet seul. php.net n’a pas publié de 8.1 nouveau. Sur Ubuntu 22.04, le paquet 8.1.2-1ubuntu2.28 contient les deux correctifs. Sans ce niveau, ou sans un rétroportage nommé par l’hébergeur, la CISA conseille de retirer le système du réseau jusqu’au correctif.

PHP 8.6 RC4 est-il un raccourci ?

Non. RC4 contient les correctifs, et PHP en interdit l’usage en production. La stable 8.6.0 est prévue le 19 novembre 2026. Le palier d’aujourd’hui reste 8.2.35, 8.3.36, 8.4.27, 8.5.12, ou le paquet de la distribution.

Du numéro lu au moteur réellement servi

La vérification tient en deux lectures : la ligne Version de PHP dans Santé du site, puis le paquet ou l’image qui produit ce numéro. Quand les deux divergent, comme sur Ubuntu 24.04, c’est le paquet qui dit si les deux failles sont corrigées. Pour reprendre les bases du web autour de ce genre de contrôle, les parcours HTML, CSS, Sass et JavaScript sont regroupés sur la page Apprentissage.