Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques. Tous les sites PHP ne sont pas exposés de la même façon, et le numéro de version affiché ne suffit pas à conclure. Je vérifie ce qui tourne réellement chez vous, je passe à la version corrigée sans casser le site, puis je contrôle que rien n’a été déposé entre-temps.
Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux failles notées 9,2 sur 10 (CVSS v4.0) : CVE-2026-109618 et CVE-2026-109619.
Toutes deux peuvent permettre à une requête non authentifiée d’exécuter du code sur le serveur. Avec Apache et mod_php, l’attaque a été démontrée avant même que le code de l’application ne s’exécute.
Les branches 8.1 et antérieures ne reçoivent plus de version officielle : le projet PHP a seulement publié des correctifs de code source pour 7.4, 8.0 et 8.1, et certaines distributions proposent leurs propres paquets corrigés.
Sources : Avis de sécurité de php.net, 21 octobre 2026, GHSA-w8hw-w9fx-j79w (CVE-2026-109618), GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
Chaque étape laisse une trace écrite : vous savez ce qui a été fait, et pourquoi.
Chaque environnement listé : serveur, conteneur ou hébergement, version exacte de PHP et du paquet, mode d’exécution (FPM, mod_php, CGI).
Si la version corrigée n’est pas encore disponible chez vous, les réglages publiés par php.net réduisent l’exposition en attendant. Ils ne remplacent pas la mise à jour.
La version corrigée de la même branche, sans version de test ni étiquette flottante, essayée sur une copie avant la production.
Fichiers en production comparés au dépôt ou aux sources officielles, recherche de fichiers PHP inattendus, lecture des journaux depuis l’annonce.
Après l’annonce du 21 octobre, je suis intervenu sur huit projets PHP. C’était une intervention préventive, pas une réponse à une attaque.
Le déroulé : inventaire des environnements, passage à la version exacte de la même branche (pas de version de test, pas d’étiquette du type « 8.5 » dont le contenu change sans prévenir), mesures temporaires là où l’image corrigée n’était pas encore disponible, puis tests.
Ensuite, un contrôle d’intégrité : fichiers déployés comparés au dépôt, recherche de fichiers PHP présents hors du dépôt, lecture des journaux. C’est l’étape qu’on oublie le plus souvent : une mise à jour ferme la faille, elle ne retire pas ce qui aurait été déposé avant.
Prix annoncés avant de commencer. Prix nets. TVA non applicable, article 293 B du CGI.
Version réelle de PHP dans chaque mode d’exécution, correctif présent ou non, réglages, dépendances. En lecture seule, compte rendu écrit sous 3 jours ouvrés. Déduit de la mise à jour commandée dans les 30 jours.
Demander un diagnosticPassage à la version corrigée de la même branche, point de retour, redémarrage de tous les workers, tests des pages clés et compte rendu avant et après. C’est le forfait intervention.
Fichiers comparés au dépôt ou aux sources officielles, fichiers PHP inattendus, comptes, tâches planifiées et journaux depuis l’annonce. Le rapport dit aussi ce qu’il ne peut pas prouver.
Site bloqué en PHP 8.1 ou 7.x : passage à une branche maintenue, avec correction des incompatibilités du code et des extensions.
Avis de PHP, de la distribution et des dépendances suivis pour vous. Correctif critique appliqué sous 3 jours ouvrés, mises à jour courantes chaque mois, compte rendu court.
La veille et les mises à jour sur tout le parc, en votre nom : 25 € par site, 40 € avec la maintenance complète. 20 sites et plus sur devis.
Pas forcément. Debian, Ubuntu ou Red Hat appliquent souvent le correctif sans changer le numéro de PHP, et l’en-tête X-Powered-By peut être masqué ou figé. Il faut regarder la version du paquet installé et la comparer au bulletin de sécurité de la distribution, ou poser la question à l’hébergeur.
Non. Les deux failles sont dans PHP lui-même, pas dans WordPress ni dans une extension. Mettre à jour WordPress ne les corrige pas : c’est la version de PHP du serveur qui compte.
Demandez à l’hébergeur si le correctif est appliqué sur la version de PHP de votre site, et gardez sa réponse par écrit. Si vous êtes encore en 8.1 ou en 7.x, il faut passer à une branche maintenue : c’est souvent là que le site casse, et c’est ce que je prépare sur une copie.
Non. php.net les présente comme une façon de réduire l’exposition, pas comme une protection : elles bloquent les chemins d’attaque démontrés, pas toutes les variantes. Elles servent à tenir quelques jours en attendant la version corrigée.
Rien ne permet de le dire sans regarder. Le contrôle d’intégrité compare les fichiers en production au dépôt ou aux sources officielles, cherche les fichiers PHP inattendus et passe en revue les journaux. S’il trouve une intrusion, on passe au nettoyage, sur devis ou au forfait selon l’étendue.
L’avis de php.net vise PHP quand il sert des requêtes web et ne cite pas la ligne de commande. Les deux sont presque toujours installés ensemble : je mets à jour l’ensemble, pour ne pas garder deux versions différentes sur le même serveur.
Pour le diagnostic, un accès en lecture suffit souvent : SSH, ou à défaut l’administration de l’hébergement et du site. Pour la mise à jour, il faut pouvoir changer la version de PHP : accès au serveur, au dépôt de l’image Docker ou au panneau de l’hébergeur.
Non, je n’assure pas d’astreinte. Je réponds sous 24 h ouvrées et j’annonce le délai avant de commencer. Si la mise à jour ne peut pas attendre, appliquez d’abord les mesures temporaires de php.net, ou demandez à votre hébergeur s’il a déjà mis à jour.
Des guides écrits à partir de cas réels, si vous préférez comprendre avant de confier.
Décrivez-le en quelques lignes. Vous recevez sous 24 h ouvrées une réponse claire : oui ou non, la formule et le délai.