Le 21 octobre 2026, l’équipe de sécurité de PHP a publié en urgence des correctifs pour deux vulnérabilités critiques, référencées CVE-2026-109618 et CVE-2026-109619. Notées 9,2 sur 10 selon le barème CVSS v4.0, elles touchent la gestion de la mémoire du moteur PHP : un site peut donc être exposé même si son propre code ne présente aucune faille connue. Pour une entreprise, une association ou une administration, le premier réflexe consiste à identifier les versions actives, puis à appliquer les mises à jour adaptées.
L’enjeu dépasse les seuls sites développés sur mesure. PHP fait fonctionner 69,3 % des sites dont le langage côté serveur est identifié, notamment des installations WordPress, Magento, Drupal et Joomla. Les vulnérabilités peuvent permettre à un attaquant distant d’exécuter du code sans compte ni mot de passe ; les systèmes qui répondent aux requêtes web sont concernés, avec un risque particulièrement élevé pour Apache utilisant mod_php. En France, l’ANSSI évoque plus de 600 000 serveurs utilisant PHP sur Internet. Plusieurs services publics ont été temporairement placés en maintenance préventive : un rappel concret qu’une interruption courte peut être préférable à une exposition prolongée.
En bref : les actions à mener face aux failles critiques de PHP
- Mettre à jour les branches maintenues vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la version utilisée.
- Recenser toutes les installations PHP, y compris celles intégrées à des outils ou services peu visibles.
- Isoler du réseau public les serveurs non corrigés jusqu’à l’installation du correctif, si cette mesure est possible.
- Vérifier les sauvegardes, redémarrer les services concernés et contrôler la version réellement active après l’intervention.
- Prévoir une migration pour les branches obsolètes : les correctifs ponctuels destinés aux versions 7.4, 8.0 et 8.1 ne remplacent pas une version maintenue.
Failles PHP CVE-2026-109618 et CVE-2026-109619 : quels risques ?
Les deux vulnérabilités se trouvent dans le moteur PHP et concernent sa gestion de la mémoire. Selon l’avis de sécurité de l’équipe PHP, leur exploitation pourrait permettre l’exécution de code sur le serveur à distance, sans authentification préalable. Le risque ne dépend donc pas seulement de la qualité du code du site : c’est aussi la version du langage et la configuration du serveur qui comptent.
Les installations exposées comprennent notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L’utilisation de mod_php est signalée comme particulièrement à risque : une seule requête pourrait suffire à déclencher l’attaque, avant même que le code de l’application soit exécuté. Autrement dit, un site qui semble fonctionner normalement n’est pas pour autant protégé.
La publication des correctifs était annoncée pour le 21 octobre à 16 heures, heure de Paris ; ils ont été mis en ligne à 15 h 30, selon le CERT-EU. L’une des vulnérabilités a été identifiée par la société Calif avec l’aide du modèle GPT-5.6 Sol, tandis que Wiz a découvert les deux failles de manière indépendante, d’après un billet d’OpenAI. La découverte assistée par IA attire l’attention, mais le point décisif reste la même action pour les équipes techniques : appliquer le correctif.
Versions de PHP corrigées : le tableau des mises à jour à installer
Les versions ci-dessous corrigent les failles dans les branches maintenues concernées. Vérifiez la branche actuellement utilisée avant toute modification : une mise à jour au sein de la même branche est généralement plus simple à tester qu’un changement majeur de version.
| Branche PHP | Version corrigée | Action recommandée |
|---|---|---|
| PHP 8.5 | 8.5.12 | Mettre à jour vers cette version ou une version ultérieure corrigée de la branche. |
| PHP 8.4 | 8.4.27 | Mettre à jour vers cette version ou une version ultérieure corrigée de la branche. |
| PHP 8.3 | 8.3.36 | Mettre à jour vers cette version ou une version ultérieure corrigée de la branche. |
| PHP 8.2 | 8.2.35 | Mettre à jour vers cette version ou une version ultérieure corrigée de la branche. |
Sur un serveur, la commande php -v permet d’afficher la version en ligne de commande. Attention : elle ne reflète pas toujours la version utilisée par le site web. Dans WordPress, vous pouvez aussi consulter Outils > Santé du site > Infos > Serveur ; après la mise à jour, vérifiez que la version active côté web a bien changé.
Pour une documentation sur les versions disponibles, consultez la page officielle des téléchargements PHP. Retenez surtout ceci : une mise à jour installée mais non utilisée par le serveur ne règle pas le problème.
Comment mettre à jour PHP sur un hébergement ou un serveur
La procédure dépend de l’environnement. Sur un hébergement mutualisé ou infogéré, demandez à l’hébergeur de confirmer que le correctif est appliqué à l’environnement qui exécute réellement votre site. Un message général annonçant une mise à jour ne suffit pas : vérifiez les versions sélectionnées pour chaque domaine ou application.
Sur cPanel ou Plesk, le changement de version s’effectue généralement dans le panneau de contrôle. Sur Linux, utilisez les paquets corrigés fournis par votre distribution. Dans tous les cas, effectuez une sauvegarde avant l’opération, puis redémarrez PHP et le serveur web si nécessaire. Terminez par un contrôle de la version active et un test des pages principales, des formulaires et des tâches automatisées.
Une petite boutique en ligne, par exemple, peut héberger sa vitrine, son espace d’administration et un outil de facturation sur des environnements PHP distincts. Mettre à jour uniquement le site public laisserait les autres installations vulnérables. Le bon réflexe est donc de dresser un inventaire complet avant de cocher la tâche comme terminée.
- Inventoriez les sites, sous-domaines, conteneurs et logiciels embarquant PHP.
- Sauvegardez les fichiers et les bases de données avant le changement.
- Appliquez le paquet corrigé ou sélectionnez la version recommandée par l’hébergeur.
- Redémarrez les services concernés et contrôlez la version réellement utilisée.
- Testez les fonctions essentielles et surveillez les journaux d’erreurs après l’opération.
Serveur PHP non corrigé : isolement et recherche de compromission
Si la mise à jour ne peut pas être faite immédiatement, le CERT-FR et le CERT-EU recommandent d’isoler les équipements concernés du réseau public, lorsque cela est possible. Le CERT-EU signale que des preuves de concept circulent déjà, ce qui augmente le risque d’exploitation rapide. Maintenir un serveur vulnérable accessible au public pendant l’attente n’est donc pas une mesure neutre.
Pour un équipement qui est resté exposé, ne vous limitez pas à installer le correctif : recherchez aussi des signes d’intrusion et appliquez les mesures de confinement. Le CERT-FR renvoie à sa fiche réflexe consacrée à la compromission d’un équipement de bordure réseau. Les équipes peuvent également conserver les journaux utiles à l’analyse et examiner les accès inhabituels, en suivant les procédures de réponse à incident de leur organisation.
Les interruptions préventives observées dans certains services publics illustrent le compromis à faire entre disponibilité et sécurité. Le ministère de l’Intérieur a temporairement placé des services en maintenance à la demande de l’ANSSI ; les usagers ont été invités à suivre les informations des préfectures par leurs canaux officiels. En situation de crise, une communication claire sur les services indisponibles évite aussi les rumeurs et les faux liens de remplacement.
PHP 5 à 8.1 : pourquoi une migration est nécessaire
Le CERT-FR classe également comme affectées les branches 5.x à 8.1.x, qui ne sont plus maintenues par le projet PHP. D’après les chiffres W3Techs fournis pour ce contexte, 26,9 % des sites utilisant PHP fonctionnent encore sous la version 7 et 7,7 % sous la version 5. Ces installations cumulent l’exposition aux vulnérabilités et l’absence de mises à jour de sécurité régulières.
Des correctifs minimaux ont été publiés pour PHP 7.4, 8.0 et 8.1 à destination des organisations qui compilent elles-mêmes le langage. Ils ne constituent pas une solution durable pour les environnements ordinaires : le CERT-FR recommande de migrer vers une branche maintenue. Avant cette migration, testez les extensions et les applications, notamment les systèmes de gestion de contenu et les modules personnalisés, afin de repérer les incompatibilités.
Pour les versions plus anciennes, un calendrier de migration avec un environnement de test et une sauvegarde vérifiée réduit les mauvaises surprises. L’objectif n’est pas seulement de rétablir le service après une mise à jour d’urgence : il est de sortir d’une situation où chaque alerte impose une intervention en mode crise.
FAQ sur les failles critiques et la mise à jour de PHP
Quelles versions de PHP faut-il installer pour corriger les failles ?
Les versions corrigées indiquées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Choisissez celle qui correspond à votre branche et vérifiez la version réellement utilisée par le site après la mise à jour.
Un site WordPress est-il concerné par les vulnérabilités PHP ?
Oui, si le serveur qui exécute WordPress utilise une version vulnérable de PHP. Le fait que le code WordPress ou ses extensions soient à jour ne remplace pas la mise à jour du moteur PHP.
Comment vérifier la version PHP de mon site ?
La commande php -v affiche la version de l’installation en ligne de commande, mais celle-ci peut différer de la version utilisée par le site. Dans WordPress, consultez Outils, Santé du site, Infos, puis Serveur, et demandez confirmation à l’hébergeur si nécessaire.
Que faire si mon serveur ne peut pas être mis à jour tout de suite ?
Dans la mesure du possible, isolez-le du réseau public jusqu’à l’application du correctif. S’il est resté exposé, vérifiez les signes éventuels de compromission et suivez les recommandations du CERT-FR pour contenir un incident.
