Le 21 octobre 2026, l'équipe de sécurité de PHP a publié en urgence les correctifs de deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619 (CVE, Common Vulnerabilities and Exposures), notées 9,2 sur 10 selon l'échelle CVSS v4.0 (Common Vulnerability Scoring System). Les deux défauts siègent dans la gestion mémoire : l'un survient quand une saturation (OOM, out of memory) interrompt PHP avant l'initialisation des données de requête ; l'autre quand un état interne survit à la libération de sa mémoire et qu'un worker ultérieur le réutilise. Dans les deux cas, l'attaquant fait exécuter son propre code au serveur.
La précision qui change tout : aucun compte, aucun mot de passe, aucune interaction. Une requête HTTP malformée suffit. Le risque est maximal sur Apache avec le module mod_php, où l'attaque se déclenche avant même l'exécution du code applicatif — donc avant le pare-feu applicatif et les contrôles d'accès. PHP-FPM (FastCGI Process Manager), php-cgi, FrankenPHP et LiteSpeed sont également concernés. Sortie annoncée pour 16 h, correctifs en ligne à 15 h 30 selon le CERT-EU, preuves de concept déjà circulantes : la fenêtre se compte en jours.
À la demande de l'ANSSI (Agence nationale de la sécurité des systèmes d'information), le ministère de l'Intérieur a placé plusieurs services exposés en maintenance préventive ; le CERT-FR a publié le même jour une alerte. Quand un ministère coupe ses sites plutôt que de parier sur son calendrier de patch, le sujet n'est pas le correctif. C'est sa mise en œuvre.
Le correctif existe ; l'installation est une autre histoire
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Sur Linux, les paquets viennent de la distribution ; sur cPanel ou Plesk, la version se change dans le panneau ; sur un mutualisé, il faut demander à l'hébergeur — et le croire sur parole.
Or une partie du parc ne peut pas être corrigée par un simple changement de version. Selon W3Techs, PHP fait tourner 69,3 % des sites dont le langage serveur est identifié, mais 26,9 % de ces sites restent sur la branche 7 et 7,7 % sur la branche 5, abandonnées par le projet. Des correctifs sources minimaux existent pour 7.4, 8.0 et 8.1, à condition de compiler soi-même — hors de portée d'un site client sur mutualisé.
Une faille critique se corrige en quelques heures. Une branche abandonnée se paie pendant des années.
Mettre à jour WordPress ne met pas à jour PHP
C'est le malentendu le plus courant. Les contrats de maintenance — quand ils existent — parlent de mises à jour du CMS (système de gestion de contenu), des extensions, des sauvegardes. La version du langage serveur y figure rarement. Un site WordPress entièrement à jour peut donc tourner sur une branche PHP abandonnée depuis deux ans sans que personne ne l'ait su.
PrestaShop ajoute une couche de friction : la compatibilité des modules. Passer de 7.4 à 8.2 casse parfois des paiements, des transporteurs ou un back-office personnalisé. La crainte est légitime, mais le comportement est prévisible : on repousse, on documente l'exception, on oublie. La dette de version est invisible jusqu'au jour où elle devient publique — et ce jour-là, elle n'est plus un arbitrage technique, c'est une urgence.
Le partage des rôles est clair. L'hébergeur sait ce qu'il a patché et doit le dire par écrit, version par version. L'agence ou le freelance qui suit le site doit tenir un inventaire : domaine, version PHP, branche, date de fin de support. Le client n'a pas à connaître les numéros, mais il a intérêt à ce que son contrat les mentionne. Un site sans inventaire de version n'est pas maintenu : il est hébergé.
Une faille trouvée par une IA, colmatée par des humains
Le détail mérite mieux qu'un titre. L'une des deux failles a été identifiée par la société Calif à l'aide du modèle GPT-5.6 Sol, et Wiz a trouvé les deux de façon indépendante, selon un billet publié par OpenAI. Pas une IA qui aurait « piraté PHP » : un outil d'analyse qui accélère la recherche de bugs mémoire dans de très grandes bases de code. La distinction compte : elle dessine l'asymétrie du moment.
La découverte de vulnérabilités s'industrialise ; leur correction, non. Un correctif se déploie au rythme des hébergeurs, des tickets, des sauvegardes et des fenêtres de maintenance. Plus les failles sont trouvées vite, plus un patch appliqué rapidement prend de valeur — et plus un parc non inventorié coûte cher. Le goulot d'étranglement n'est plus dans la recherche, il est dans la logistique.
Ce qu'il faut vérifier, concrètement
- Relever la version active de chaque site : php -v, Santé du site dans WordPress, ou le sélecteur de version dans cPanel/Plesk.
- Comparer aux versions corrigées : 8.5.12, 8.4.27, 8.3.36, 8.2.35.
- Obtenir une confirmation écrite de l'hébergeur pour les sites mutualisés, avec la version réellement servie après l'opération.
- Sauvegarder la base et les fichiers, puis redémarrer PHP et le serveur web : un worker garde sa version tant qu'il n'est pas relancé.
- Sur une branche non maintenue, planifier une migration. Les mesures d'atténuation recommandées par PHP (mémoire non plafonnée, session.upload_progress.enabled=0, fatal_error_backtraces=0 sur 8.5) réduisent certains chemins d'attaque, sans rendre une installation sûre.
- Inscrire la version PHP et la politique de mise à jour dans le contrat de maintenance. Ce qui n'est pas écrit ne sera pas fait.
Ce qu'on ne sait pas encore
Trois inconnues. L'ampleur réelle des exploitations : des preuves de concept circulent, ce qui ne prouve pas un usage massif. Le comportement des hébergeurs : certains ont probablement patché sans changer le numéro de version affiché, d'autres annoncent un correctif sans date d'application. Le nombre de sites réellement bloqués sur une branche morte, enfin — W3Techs donne un ordre de grandeur, pas un inventaire.
Ce qui est établi tient en une phrase : la faille était dans le langage, mais le risque est dans l'organisation. Un site dont personne ne connaît la version PHP n'est pas un site dont on ignore un détail. C'est un site dont on ignore l'état.