« Nous sommes en PHP 8.2 à 8.5. »
Appliquer le correctif. Mise à jour dès la publication, sur chaque serveur et chaque conteneur, puis vérification de la version réellement servie et des parcours essentiels de l’application.
Alerte sécurité PHP · 21 octobre 2026
Faille critique dans PHP.
Corriger vite.
Migrer proprement.
Deux failles d’exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, touchent le moteur PHP lui-même. J’applique le correctif sur vos serveurs dès sa publication, et je migre vers PHP 8.4 les applications restées sur une version qui n’en recevra pas.
Réponse sous 24 h ouvrées. Un interlocuteur direct, développeur PHP depuis près de huit ans.
Selon votre version de PHP
Trois situations.
Une réponse adaptée.
« Nous sommes en PHP 8.1, 7 ou plus ancien. »
Migrer vers PHP 8.4. Ces versions ne recevront pas de correctif officiel. Je mets à jour le code et les dépendances, je teste sur une copie, puis je mets en production avec un retour arrière prévu.
« Nous ne savons pas. »
Faire le point. Versions en service, serveurs exposés, ce que fait ou non votre hébergeur : un état des lieux court pour décider vite.
Pourquoi PHP 8.4
Des correctifs de sécurité jusqu’au 31 décembre 2028.
Une version mûre, prise en charge par les principaux frameworks et hébergeurs. La migration vous met à l’abri pour plusieurs années, au lieu d’un correctif d’urgence à refaire.
La méthode
Vite, sans casser
ce qui fonctionne.
Une intervention de sécurité reste une mise en production : elle se prépare, se teste et se trace.
- 01 / Inventorier
Savoir ce qui tourne.
Versions de PHP réellement servies (web, CLI, tâches planifiées, conteneurs), hébergement et dépendances.
- 02 / Corriger
Mettre à jour.
Version corrigée dès sa sortie, ou migration vers PHP 8.4 sur une copie de l’application.
- 03 / Vérifier
Tester l’essentiel.
Parcours critiques, journaux d’erreurs, extensions et tâches planifiées.
- 04 / Livrer
Mettre en production.
Bascule planifiée avec retour arrière prévu, puis un compte rendu écrit de ce qui a changé.
En attendant le correctif
Ce que vous pouvez
faire dès maintenant.
Quatre vérifications qui feront gagner du temps le jour de la mise à jour, avec ou sans mon aide.
Lister ce qui exécute PHP.
Serveurs, hébergements et conteneurs, avec leur version. La commande php -v ne dit pas toujours ce que sert le site : vérifiez aussi PHP-FPM et les images Docker.
Rendre la mise à jour prête à appliquer.
Dépôts de paquets, images de base et fenêtre de maintenance : tout ce qui permet d’installer la version corrigée dès sa publication.
Suivre le bon numéro de version.
Si PHP vient des paquets de votre distribution (Debian, Ubuntu, Red Hat…), le numéro peut rester le même : c’est le correctif publié par la distribution qui compte.
Vérifier la version choisie.
Dans le panneau de votre hébergeur, une version 8.1 ou plus ancienne ne sera pas corrigée : c’est le moment de passer à 8.4.
Qui intervient
Mathieu Mont, développeur PHP et Symfony.
Près de huit ans à concevoir, reprendre et faire évoluer des applications PHP en production : applications métier, API, montées de version. Dernière en date : l’application web Symfony qui remplace la base Access des achats d’un grand groupe industriel.
Questions fréquentes
Avant d’intervenir.
Mon site est-il concerné ?
Toute application qui exécute PHP doit être considérée comme concernée tant que la version corrigée n’est pas installée. Les conditions précises d’exploitation seront publiées avec le correctif ; l’état des lieux permet de savoir où vous en êtes sans attendre.
Mon hébergeur ne s’en occupe-t-il pas ?
Sur un hébergement mutualisé, l’hébergeur met généralement PHP à jour, mais c’est souvent vous qui choisissez la version dans son panneau : une version 8.1 ou plus ancienne ne sera pas corrigée. Sur un serveur dédié, un VPS ou dans le cloud, la mise à jour est à votre charge.
Pourquoi migrer vers PHP 8.4 plutôt que de rester où nous sommes ?
PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs de sécurité : pour elles, migrer est la seule voie officielle. PHP 8.4 est maintenu jusqu’à fin 2028, ce qui évite de refaire le travail dans un an.
Combien coûte une intervention ?
Cela dépend du nombre de serveurs, de la version de départ et de l’état du code. Après un premier échange, vous recevez un devis ferme avant toute intervention.
Sur quelles applications intervenez-vous ?
Applications Symfony, Laravel, WordPress ou PHP sans framework, hébergées chez vous, chez un hébergeur ou dans le cloud. Intervention à distance partout en France, sur place à Lyon et Saint-Étienne.
Que faut-il me donner comme accès ?
Rien à ce stade. Pour l’intervention : des accès temporaires et nominatifs, retirés à la fin. Aucun mot de passe ne doit transiter par e-mail ou par ce formulaire.
Sources, consultées le 21 octobre 2026
- BleepingComputer : l’équipe PHP annonce deux failles critiques et des correctifs d’urgence
- watchTowr : questions fréquentes sur CVE-2026-109618 et CVE-2026-109619
- Sansec : PHP2Shell
- Huntress : les failles PHP qui ont fuité
- php.net : annonces et versions officielles
Atelier Mont n’est pas affilié au projet PHP. Cette page sera mise à jour avec les versions corrigées dès leur publication.