Mise à jour du 24 octobre 2026 : le 23 octobre, le projet PHP a publié un avis d’information sur un troisième problème, jugé peu probable, la CVE-2026-115560, liée à session.upload_progress. Il ne peut se produire que si une application règle session.serialize_handler sur php_binary ou php_serialize, puis le repasse sur php en cours d’exécution avec ini_set() avant d’appeler session_start(), alors que le suivi de progression des envois de session reste activé. D’ici la prochaine version de correctifs, le projet suggère de définir session.upload_progress.enabled=0. Si vous avez déjà appliqué ce réglage comme mesure d’atténuation de la CVE-2026-109619, conservez-le : aucune autre action n’est nécessaire. Un avis complet sera publié avec la prochaine version. Source : php.net, 23 octobre 2026.
Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux vulnérabilités logées dans le moteur PHP lui-même, pas dans un thème ou une extension WordPress. Les deux affichent un score CVSS v4.0 de 9,2, et les deux permettent à un attaquant d’exécuter son propre code sur le serveur sans se connecter, sans mot de passe, sans qu’un tiers ait besoin de cliquer sur quoi que ce soit. WordPress tourne sur PHP partout, d’un hébergement mutualisé à un cluster managé d’entreprise : cette publication touche donc quasiment tous les sites WordPress en ligne. Allons voir ce qui se passe vraiment, ensemble.
Pourquoi ces deux failles ne demandent aucune connexion
Ce n’est pas la première fois qu’une faille au surnom de bande dessinée nous force à une mise à jour imprévue sur ce site. wp2shell, la faille du cœur de WordPress que nous avions couverte plus tôt cette année, vivait dans WordPress lui-même, et elle était déjà activement exploitée au moment où nous en parlions. La paire corrigée cette semaine mérite d’être distinguée clairement : la communauté sécurité l’a déjà surnommée « PHP2Shell », et malgré la ressemblance du nom, aucun des deux CVE ne touche la moindre ligne de code WordPress. Les deux vivent dans PHP, le langage dans lequel WordPress est écrit et sur lequel il tourne, une couche plus bas que ne l’était wp2shell.
Selon l’avis de sécurité officiel du projet PHP, CVE-2026-109618 se déclenche quand une requête atteint la limite mémoire de PHP au pire moment possible : le moteur peut alors laisser des données internes de requête partiellement initialisées, puis les traiter comme valides une fois le nettoyage de la requête effectué. CVE-2026-109619 fonctionne autrement. Une erreur fatale survenue au mauvais instant peut laisser un état interne pointer vers une zone mémoire qui appartenait à une requête précédente, une zone qu’une requête suivante, traitée par le même worker, peut atteindre avant la réinitialisation normale. Aucun des deux chemins ne demande à l’attaquant de prouver son identité. Le billet officiel de la PHP Foundation désigne Apache avec mod_php comme la configuration la plus exposée, avec un exploit démontré qui s’exécute avant même que le moindre code WordPress ne démarre.
Certains relais ont d’abord repris un score CVSS de 10,0. La PHP Foundation a depuis corrigé publiquement ce chiffre : le score confirmé pour les deux failles est bien 9,2. Plus difficile à balayer, en revanche, c’est ce qui s’est passé depuis la publication du correctif. Les chercheurs en sécurité de watchTowr indiquent que leur réseau de pots de miel détecte des tentatives d’exploitation depuis le jour même de la publication, et un code de preuve de concept circule publiquement depuis le 22 octobre. Selon les dernières indications du centre canadien officiel pour la cybersécurité, aucune compromission réussie n’a pour l’instant été confirmée sur l’une ou l’autre des deux failles, même si l’avis lui-même prévient que la situation peut évoluer vite. À prendre pour ce que c’est : une fenêtre courte, pas une garantie.
Être à jour sur WordPress ne veut pas dire que LE serveur l’est
WordPress.org a relayé l’alerte le jour même, et son propre article est étonnamment direct sur ce que cela signifie pour les propriétaires de site. Cette annonce pose une chose explicitement : aucune mise à jour de WordPress n’est nécessaire ni prévue pour ces deux failles, parce que la vulnérabilité se situe en dehors de tout ce que le cœur de WordPress contrôle. Cette phrase est tout l’enjeu de cet article. Un site peut tourner sur la toute dernière version de WordPress, le thème le plus récent, chaque extension parfaitement à jour, et rester pourtant exposé, parce que la faille vit une couche en dessous du CMS, dans l’interpréteur PHP qui le fait tourner.
Qui a la responsabilité de cette couche dépend entièrement du type d’hébergement. Sur un hébergement mutualisé, c’est l’hébergeur qui fait tourner PHP pour tous ses clients sur le même serveur, et il pousse en général la mise à jour sans action de votre part, même s’il reste plus prudent de vérifier que de simplement le supposer. Sur un VPS, un serveur dédié, ou toute installation auto-gérée, mettre à jour PHP est votre tâche, pas celle de l’hébergeur, et personne ne la pousse automatiquement à votre place. La consigne de WordPress.org pour ce second cas est sans détour : les propriétaires de site encore sur une version de PHP antérieure à 8.2 sont invités à envisager de mettre le serveur hors ligne le temps de la mise à jour, parce que ces branches plus anciennes ne reçoivent plus de vrai correctif, seulement des rétroportages partiels.
Êtes-vous exposé ? La vérification de deux minutes
Vérifions votre site ensemble, cela prend moins de temps que la lecture de ce paragraphe. Ouvrez votre tableau de bord WordPress, allez dans Outils, puis Santé du site, puis l’onglet Informations, et regardez sous Serveur. La version de PHP qui fait tourner votre site est affichée là, exactement le chemin que WordPress.org indique lui-même dans son avis. Si le numéro affiché est 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou toute version supérieure dans chaque branche, vous êtes déjà couvert. Tout numéro plus ancien demande une action.
Sur un hébergement mutualisé, le chemin le plus rapide reste le chat support ou le panneau de contrôle de votre hébergeur : la plupart exposent un sélecteur de version PHP directement dans cPanel ou leur propre tableau de bord. Si vous gérez votre propre serveur, la mise à jour passe par votre gestionnaire de paquets ou votre image de conteneur, comme toute autre montée de version PHP. Une date mérite d’être retenue dans tous les cas : PHP 8.2 arrive en fin de vie le 31 décembre 2026, donc corriger vers 8.2.35 aujourd’hui n’achète qu’environ deux mois avant que cette branche cesse complètement de recevoir des correctifs, y compris le prochain du même genre.
Si vous ne pouvez pas corriger ce soir
Le projet PHP est explicite : rien de ce qui suit ne remplace la mise à jour. Il n’existe aucune mitigation complète sans mise à jour, seulement des moyens de réduire l’exposition en attendant. Pour CVE-2026-109618, l’avis du projet recommande de régler memory_limit=-1 pour qu’une requête ne puisse pas être interrompue en heurtant un plafond mémoire fini, combiné à un post_max_size bas, 8M si le site n’a pas besoin d’uploads, 32M s’il en a besoin, avec upload_max_filesize maintenu sous ce chiffre. Pour CVE-2026-109619, l’avis demande session.upload_progress.enabled=0, appliqué via php.ini ou la configuration serveur plutôt qu’à l’exécution, et sur PHP 8.5 spécifiquement, fatal_error_backtraces=0 également. Chacun de ces réglages exige un redémarrage complet des workers pour prendre effet : modifier le réglage sans redémarrer PHP-FPM ou Apache laisse tourner l’ancien comportement vulnérable sous le nouveau fichier de configuration.
Notre avis
Nous avons déjà écrit sur ce qu’une version de sécurité WordPress corrige vraiment, et le réflexe que cet article essayait de construire s’applique encore ici : vérifiez le numéro de version vous-même, ne supposez pas qu’un badge « à jour » couvre tout ce qui se trouve en dessous. Cette fois, le numéro qui compte n’est même pas celui que WordPress affiche. Si vous gérez votre propre serveur, mettez à jour PHP ce soir plutôt que d’attendre votre prochaine fenêtre de maintenance, et si vous êtes en mutualisé, un court message à votre hébergeur pour confirmer que le correctif est bien en place vaut la peine d’être envoyé, même si son panneau affiche déjà la correction. Cette faille n’a rien de spectaculaire à l’écran : aucun écran d’administration volé, aucune page d’accueil défigurée, juste un numéro de version resté en silence trop ancien. C’est généralement comme cela que la couche sous celle qu’on surveille finit par passer inaperçue.
Photo : Christina Morillo/Pexels.
