Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre à un attaquant d’exécuter du code sur un serveur sans se connecter. Si votre site web tourne sous PHP, comme tous les sites WordPress, c’est à vérifier dès aujourd’hui. Voici ce qui s’est passé, ce qu’il faut faire et comment nous avons traité le problème sur les sites que nous gérons.
Que sont CVE-2026-109618 et CVE-2026-109619 ?
Il s’agit dans les deux cas de failles de PHP lui-même, chacune notée 9,2 sur l’échelle CVSS v4.0, que le projet PHP qualifie de critiques. Elles permettent l’exécution de code à distance sans authentification : une personne sans aucun compte sur votre site pourrait faire exécuter son propre code par votre serveur.
- CVE-2026-109618 : lorsque PHP manque de mémoire, il peut être interrompu alors que ses données internes de requête ne sont qu’à moitié initialisées, et le nettoyage qui suit risque de traiter ces données invalides comme valides.
- CVE-2026-109619 : des données internes appartenant à une requête peuvent survivre à la mémoire vers laquelle elles pointaient, et une requête ultérieure traitée par le même worker risque de les utiliser.
Votre site web est-il concerné ?
Très probablement, s’il repose sur PHP et n’a pas été mis à jour depuis. L’avis de sécurité couvre toute installation PHP qui traite des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, et juge le risque le plus élevé avec mod_php.
Tenir à jour WordPress, votre thème et vos extensions est une bonne pratique, que nous recommandons dans notre guide de sécurité WordPress, mais cela ne corrige pas cette faille. Elle se situe dans la couche qui se trouve en dessous.
Que faire maintenant
- Identifiez votre version de PHP. Dans WordPress : Outils, Santé du site, Infos, Serveur.
- Passez à une version corrigée : PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Sur un hébergement infogéré, demandez à votre hébergeur de confirmer que c’est fait.
- Vérifiez que la nouvelle version tourne vraiment. Les processus PHP doivent redémarrer pour la charger.
- Sauvegardez d’abord, puis testez. Vérifiez votre page d’accueil, vos formulaires, votre tunnel de commande et votre back-office juste après.
- Anticipez si vous êtes sur une ancienne branche. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet, et PHP 8.2 arrive en fin de vie le 31 décembre 2026.
Si vous ne pouvez pas mettre à jour immédiatement, l’avis de sécurité indique des réglages provisoires. De son propre aveu, ils réduisent l’exposition sans la supprimer, et la mise à jour reste la seule option sûre.
Ce que notre équipe a fait
Nous assurons la maintenance des sites web que nous réalisons, sur notre propre serveur : c’était donc à nous d’agir. Le projet PHP a publié les correctifs le 21 octobre à 14 h UTC. Le lendemain à 9 h 27 UTC, moins de 20 heures plus tard, notre mise à jour était en cours. Voici ce que nous avons fait :
- D’abord une sauvegarde. Nous avons enregistré la configuration PHP et la liste des paquets installés, pour pouvoir revenir en arrière en cas d’échec.
- Uniquement ce que le correctif exigeait. Nous avons mis à jour les paquets PHP et rien d’autre, sans toucher aux réglages des sites.
- Toutes les branches maintenues. Nous avons passé 8.2, 8.3, 8.4 et 8.5 à leurs versions corrigées, et pas seulement la version qu’utilisent nos sites.
- Une vérification de chaque site. Nous avons ensuite chargé les sites un par un, pages de contact et versions traduites comprises, et confirmé que chacun répondait normalement.
Rien d’héroïque là-dedans. C’est simplement le rôle de la maintenance et du support : quelqu’un surveille déjà quand l’alerte tombe, connaît la configuration du serveur et a une solution de retour en arrière prête. Pour en savoir plus sur ce que ce travail implique, consultez notre checklist de maintenance de site web.
Les questions à poser à la personne qui gère votre site web
- Quelle version de PHP fait tourner mon site, et quand a-t-elle été mise à jour pour la dernière fois ?
- Comment seriez-vous informé d’une vulnérabilité critique, et dans quel délai agiriez-vous ?
- Existe-t-il une sauvegarde récente, et quelqu’un a-t-il déjà essayé de la restaurer ?
- Qui vérifie le site après une mise à jour ?
Si ces questions n’ont pas de réponse rapide, mieux vaut y remédier avant le prochain avis de sécurité.
Questions fréquentes
Quelles versions de PHP corrigent CVE-2026-109618 et CVE-2026-109619 ?
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, selon l’avis de sécurité du projet PHP. Votre numéro de version doit correspondre à l’une de ces versions ou à une version ultérieure ; sinon, votre fournisseur doit confirmer qu’il a rétroporté les correctifs.
Un site WordPress peut-il être concerné ?
Oui, si le PHP sur lequel il repose n’est pas corrigé. Les failles se trouvent dans PHP lui-même : elles ne dépendent ni de votre thème ni de vos extensions, et mettre à jour WordPress ne les corrige pas. La mise à jour doit se faire sur le serveur.
Un pare-feu ou un réglage du serveur suffit-il à me protéger ?
Pas entièrement. L’avis de sécurité indique des réglages provisoires qui réduisent l’exposition, et précise qu’ils ne suffisent pas à sécuriser une installation. La mise à jour reste la seule option sûre.
Et si mon site tourne sous PHP 8.1 ou une version antérieure ?
Le projet PHP ne publie plus de mises à jour pour ces versions. L’avis de sécurité indique que certains fournisseurs rétroportent des correctifs : renseignez-vous auprès du vôtre, ou passez à une version maintenue. PHP 8.2 lui-même ne recevra plus de correctifs de sécurité après le 31 décembre 2026.
Comment savoir quelle version de PHP utilise mon site ?
Dans WordPress, ouvrez Outils, puis Santé du site, puis Infos, puis Serveur. Ailleurs, le panneau de votre hébergement l’indique en général ; sinon, votre hébergeur ou votre développeur peut vous la communiquer.
Vous ne savez pas si votre site a été mis à jour ? Envoyez-nous son adresse et nous vous dirons quoi vérifier.
