Deux CVE à 9,2 de score, une fuite, et une majorité de serveurs laissés sans patch
Le 21 octobre 2026, l'équipe PHP publie en urgence une version de sécurité corrigeant deux vulnérabilités critiques du cœur du langage : CVE-2026-109618 et CVE-2026-109619. Surnommées « php2shell », elles ont chacune un score CVSS v4.0 de 9,2. Leur détail a circulé sur Hacker News environ un jour avant la fin de l'embargo, ce qui a poussé l'équipe à avancer la publication. Le cabinet watchTowr a confirmé que les failles étaient réelles et en a reproduit une en laboratoire. Cet article résume ce qui est établi, ce qui reste à vérifier et ce qu'il faut faire dès maintenant. Il s'appuie sur l'analyse publiée par Temuri Takalandze : php2shell: Two Critical PHP Core Bugs Leaked Before the Patch.
Ce qui est confirmé, et les chiffres à corriger
Plusieurs chiffres circulent, et certains sont faux. Le message initial qui a fuité évoquait un score CVSS de 10,0. Le score officiel est de 9,2, ce qui reste très élevé : on parle de failles du runtime lui-même, pas d'une bibliothèque tierce que l'on pourrait ne pas utiliser.
Ce qui est solide :
- Deux CVE distinctes, notées chacune 9,2 en CVSS v4.0.
- Une fuite publique avant la fin de l'embargo.
- Une confirmation indépendante par watchTowr, avec reproduction d'une des deux failles.
- Une publication avancée d'un jour par l'équipe PHP.
Le surnom « php2shell » laisse entendre qu'une exploitation réussie peut mener à l'exécution de commandes sur le serveur. Les détails techniques précis restent à lire dans les avis officiels et dans le billet d'origine, qui distingue ce qui est confirmé de ce qui relève encore de la rumeur.
Le vrai risque : les versions qui ne recevront aucun correctif
L'équipe PHP ne maintient officiellement que les versions 8.2 et supérieures. Or, d'après les chiffres cités par la source, 59 % des hôtes exposés sur Internet qui affichent une version de PHP tournent en 8.1 ou plus ancien. Ces serveurs ne recevront pas de patch officiel.
Plusieurs nuances s'imposent :
- Certaines distributions Linux rétroportent les correctifs de sécurité sur d'anciennes versions. Consultez le suivi de sécurité de la vôtre avant de conclure qu'une machine est vulnérable.
- Le numéro de version affiché n'est pas toujours le reflet exact de l'état de correction d'un paquet rétroporté.
- Les installations oubliées sont les plus dangereuses : images Docker anciennes, appliances, environnements de recette jamais mis à jour.
Que faire aujourd'hui
La démarche tient en quelques étapes, dans cet ordre.
1. Faire l'inventaire complet
Recensez chaque installation de PHP, y compris celles qui ne sont pas sur vos serveurs « principaux » : conteneurs, images de base utilisées dans vos pipelines, outils internes, appliances fournies par des tiers. Dans un environnement Docker, vérifiez la version de PHP de chaque image, pas seulement celle de l'hôte.
2. Identifier ce qui est hors support
Tout ce qui tourne en dessous de PHP 8.2 doit être traité comme prioritaire. Deux options : confirmer auprès de votre distribution qu'un rétroportage existe, ou planifier la montée de version. Pour les projets Symfony, vérifiez la compatibilité de votre version du framework et de vos dépendances avec la version de PHP visée avant de lancer la migration.
3. Appliquer la mise à jour et redémarrer
Une fois la version corrigée disponible pour votre branche, installez-la, puis redémarrez PHP-FPM. Sans redémarrage, les processus déjà lancés continuent d'exécuter l'ancien code en mémoire. Faites de même pour tout autre mode d'exécution que vous utilisez (serveur applicatif, image Docker à reconstruire et redéployer).
4. Surveiller en attendant
Tant que le correctif n'est pas déployé, renforcez la surveillance des journaux d'accès et des comportements anormaux sur vos serveurs exposés. Le billet d'origine propose en outre une liste de contrôle et un signal de détection utilisable immédiatement.
Conclusion
Cette affaire rappelle deux réalités. D'abord, un embargo ne protège que tant qu'il tient : une fuite réduit à presque rien le délai dont disposent les équipes pour réagir. Ensuite, la dette de version se paie tôt ou tard : une version hors support n'est plus un simple retard de confort, c'est un angle mort de sécurité. Faites l'inventaire aujourd'hui, planifiez la montée de version de tout ce qui est antérieur à 8.2, et appliquez le correctif dès sa disponibilité. Pour le détail des éléments confirmés et des rumeurs, reportez-vous à la source : php2shell: Two Critical PHP Core Bugs Leaked Before the Patch.
Ce que ça change pour vous
Si votre site ou votre logiciel métier repose sur PHP, une faille de ce type peut permettre à un tiers de prendre le contrôle du serveur qui l'héberge. Plus de la moitié des serveurs visibles sur Internet utilisent des versions que l'éditeur ne corrigera plus. Demandez dès maintenant à votre prestataire quelle version de PHP vous utilisez, si elle est encore supportée, et à quelle date la mise à jour est prévue. Ce n'est pas une question de confort technique : c'est la protection de vos données, de vos clients et de votre activité.
