Le 21 octobre 2026, l’équipe de sécurité du projet PHP a publié quatre nouvelles versions en urgence : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux failles critiques, répertoriées CVE-2026-109618 et CVE-2026-109619, capables de permettre l’exécution de code à distance sans authentification sur tout serveur qui fait tourner du PHP, selon l’annonce officielle du projet (php.net, 21 octobre).
Pour qui gère un site WordPress sans équipe technique en interne, l’annonce est anxiogène par construction : une faille critique, un score de gravité maximal, des versions à changer dans l’urgence. Notre article sur la sécurité des applications web le rappelait déjà : la plupart des risques qui pèsent sur un site ne viennent pas de WordPress lui-même, mais de la pile logicielle qui le fait fonctionner. Cette semaine en est une illustration directe.
Les deux failles ont d’abord circulé avec un score erroné de 10,0 sur 10 ; le score réel, en échelle CVSS v4.0, est de 9,2, a corrigé la PHP Foundation. Côté WordPress, la position officielle est nette : « aucune mise à jour de WordPress n’est nécessaire ni prévue » pour ces failles, précise un billet de wordpress.org daté du 21 octobre. Le correctif se joue ailleurs, chez l’hébergeur.
Table des matières
Chronologie du 19 août au 23 octobre
- 19 août : selon Wiz Research, première découverte de la faille liée à la gestion de la mémoire.
- 24 août : signalement de Wiz Research à l’équipe de sécurité de PHP, un point sur lequel les deux récits de l’affaire convergent.
- 18 septembre : selon la PHP Foundation, un signalement indépendant précise des vecteurs d’attaque supplémentaires.
- 20 octobre, vers 15h00 UTC : les identifiants CVE commencent à circuler sur des forums publics, avec une date de publication et un score erronés.
- 20 octobre, vers 20h00 UTC : une démonstration technique est publiée par erreur par un chercheur associé au signalement initial, dans la foulée de la fuite.
- 21 octobre, 07h41 UTC : un éditeur de conteneurs publie par anticipation des images déjà corrigées, plus de six heures avant l’heure d’embargo prévue.
- 21 octobre : le projet PHP avance sa publication officielle, initialement prévue le 22, et diffuse les quatre versions corrigées.
- 21 octobre, 14h19 UTC : la société watchTowr indique observer, via son réseau de pots de miel, des tentatives d’exploitation des deux failles.
- 23 octobre : php.net publie un avis complémentaire sur une troisième faille, CVE-2026-115560, jugée improbable en conditions réelles.
Ce qui est établi, ce qui est rapporté, ce qui reste contesté
Ce qui est établi
Les versions corrigées sont connues et datées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, disponibles depuis le 21 octobre selon php.net. Pour les branches 7.4, 8.0 et 8.1, qui ne reçoivent plus de nouvelle version officielle, seuls des correctifs sources minimalistes ont été publiés. PHP 8.2, de son côté, reste maintenu en sécurité jusqu’au 31 décembre 2026. Le risque le plus élevé concerne les configurations Apache avec mod_php, où une requête non authentifiée peut déclencher la faille avant même l’exécution du code applicatif, selon la description technique du projet PHP.
Un hébergeur, SiteGround, a publié sur son propre blog, le 21 octobre, la confirmation que le correctif avait été appliqué sur l’ensemble de ses serveurs ; plusieurs autres hébergeurs ont fait des annonces similaires dans les jours suivants.
Ce qui est rapporté, à attribuer
Deux récits distincts circulent sur la découverte de la faille, sans que l’un ne recoupe exactement l’autre. Wiz Research, dans son propre billet, situe la première découverte au 19 août et un signalement à l’équipe PHP le 24 août. La PHP Foundation, dans sa version des faits, remonte plus loin : un développeur du cœur du langage avait repéré, dès 2024, les premiers signes du problème de gestion mémoire, sans qu’un vecteur d’exploitation concret soit alors identifié ; c’est un signalement distinct, daté du 11 août, qui a fait de cette faille une priorité pour son équipe de sécurité. Plusieurs équipes ont signalé le même défaut, sans qu’aucune des deux versions ne tranche la question de la paternité.
Wiz Research affirme, dans ce même billet, avoir reproduit l’exécution de code à distance sur des installations neuves de WordPress, de Drupal et de Joomla, en utilisant les images de conteneurs les plus récentes au moment du test. Selon des statistiques W3Techs datées du 23 octobre, PHP reste utilisé par 69,3 % des sites dont le langage serveur est identifiable ; une lecture de ces mêmes chiffres par la société de sécurité Island évalue à près de la moitié la part de ces sites qui tournent encore sur une version de PHP non maintenue.
Le gouvernement britannique a par ailleurs confirmé, devant le Parlement le 22 octobre, avoir mis hors ligne par précaution 32 services publics et en avoir dégradé quatre autres, tout en précisant n’avoir connaissance d’aucune compromission confirmée des systèmes concernés, selon des propos rapportés par The Register.
Ce qui reste contesté
La publication anticipée du correctif par l’éditeur de conteneurs à l’origine de la fuite fait l’objet d’un désaccord assumé entre les parties. Son dirigeant a justifié cette décision par des tentatives d’exploitation déjà observées ; un membre du conseil de la PHP Foundation a répondu qu’aucune preuve de ce type n’existait à ce moment-là.
L’état réel de l’exploitation ne fait pas consensus à la date du 23 octobre. watchTowr indique observer des tentatives via son réseau de pots de miel depuis le 21 octobre, 14h19 UTC. Le Centre canadien pour la cybersécurité, dans son avis AL26-026, évoque une preuve de concept disponible publiquement sans exploitation active identifiée à la date de son bulletin. Les deux failles ne figuraient pas, au 23 octobre, dans le catalogue des vulnérabilités activement exploitées publié par l’agence américaine CISA. Tentatives observées et compromission confirmée restent deux choses différentes.
Pourquoi WordPress n’y peut rien
La faille ne vient pas d’un thème, d’une extension ou du cœur de WordPress : elle est dans l’interpréteur PHP lui-même, la couche logicielle qui exécute le code de n’importe quelle application web avant même que WordPress n’entre en jeu. C’est pour cette raison que wordpress.org a pu écrire, dès le 21 octobre, qu’aucune mise à jour de WordPress n’était nécessaire ni prévue. Mettre à jour WordPress, ses thèmes ou ses extensions ne change rien à l’exposition d’un site tant que la version de PHP sur laquelle il tourne n’est pas elle-même corrigée. Cette mise à jour relève de l’hébergeur, qui gère la configuration serveur, ou de l’infogéreur du site lorsque ce rôle est externalisé.
Les versions antérieures à PHP 8.2 compliquent la donne. PHP 7.4, 8.0 et 8.1 ne reçoivent plus de nouvelle version officielle du tout, seulement des correctifs sources que chaque distribution ou hébergeur doit intégrer lui-même. Quant à PHP 8.2, sa fenêtre de maintenance en sécurité se referme le 31 décembre 2026, ce qui en fait une version à surveiller pour la suite, même si elle est corrigée aujourd’hui.
Ce que cela change pour un site de TPE ou de PME
Pour le responsable d’un site WordPress sans équipe technique en interne, l’épisode se résume à quelques vérifications concrètes plutôt qu’à une alerte généralisée. Savoir quelle version de PHP fait tourner le site est la première étape : elle s’affiche dans WordPress, sous Outils puis Santé du site, à la rubrique Informations. Obtenir ensuite une confirmation écrite de l’hébergeur que le correctif a bien été appliqué évite de se fier à une simple hypothèse. Demander si les journaux serveur du 20 au 22 octobre ont été vérifiés pour une activité suspecte complète le tableau, sans présumer d’un incident. Noter enfin l’avis du 23 octobre sur session.upload_progress reste utile si le site utilise des fonctionnalités d’upload avancées, même si le risque y est décrit comme limité en pratique.
Voir aussi notre article sur la maintenance d’un site WordPress et notre guide pour bien choisir son hébergement web.
Sources
Principales sources de cet article, toutes datées d’octobre 2026. Les autres déclarations citées dans le texte sont attribuées à leur auteur au fil des paragraphes.
- php.net, avis de sécurité du 21 octobre et avis complémentaire du 23 octobre
- wordpress.org/news, billet du 21 octobre
- PHP Foundation, billet du 21 octobre
- watchTowr, avis technique
Crédits photo : StockSnap et dlohner, Pixabay.
PHP: 2026-10-24 17:06:28 [notice X 0][/home/riol1133/agence-tellit.com/wp-content/plugins/elementor-pro/modules/forms/submissions/actions/save-to-database.php::193] {closure:ElementorPro\Modules\Forms\Submissions\Actions\Save_To_Database::__construct():193}(): Implicitly marking parameter $exception as nullable is deprecated, the explicit nullable type must be used instead [array ( ‘trace’ => ‘ #0: Elementor\Core\Logger\Manager -> shutdown() ‘, )]
