Deux failles critiques de PHP, notées 9,2/10, menacent les sites web professionnels. Des correctifs sont disponibles : les PME et e-commerçants doivent agir sans délai.
Failles critiques PHP : les entreprises face au risque de panne et de cyberattaque
By
Last modified on 21 octobre 2026 15h52
Une alerte informatique aux conséquences potentiellement économiques majeures. Ce mercredi 21 octobre 2026, l’écosystème du Web fait face à deux vulnérabilités critiques dans PHP, un langage utilisé par des millions de sites, dont de nombreuses boutiques en ligne. Les correctifs sont désormais disponibles, mais les entreprises doivent encore les installer sur leurs infrastructures ou les faire appliquer par leur hébergeur. En jeu : la sécurité des services en ligne, la continuité des ventes et la confiance des clients.
Deux failles de gravité 9,2 sur 10 : ce que l’on sait
Les vulnérabilités CVE-2026-109618 et CVE-2026-109619 sont toutes deux notées 9,2 sur 10 selon le référentiel CVSS v4.0. L’équipe de sécurité de PHP indique qu’elles peuvent permettre une exécution de code à distance sans authentification : dans certaines conditions, un attaquant peut provoquer l’exécution de code sur un serveur sans disposer d’un compte autorisé.
Les deux mécanismes sont distincts. Le premier concerne la gestion d’un manque de mémoire et la manipulation de données internes partiellement initialisées. Le second touche à un état interne conservé après libération de la mémoire. Leur portée varie selon la configuration du serveur. Selon l’éditeur, les installations accessibles sur le Web utilisant notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed sont concernées ; le risque est jugé particulièrement élevé avec mod_php.
Dans son bulletin d’alerte publié le 21 octobre, le CERT-FR, service de veille et de réponse de l’ANSSI, appelle à traiter rapidement les systèmes affectés. La publication initialement annoncée pour 16 heures, heure de Paris, a laissé peu de temps aux équipes informatiques pour s’organiser.
Pourquoi les PME et le commerce en ligne sont en première ligne
PHP ne se limite pas aux sites de développeurs. C’est l’un des socles techniques de WordPress et d’une partie de l’écosystème des sites éditoriaux, institutionnels et marchands. Selon W3Techs, il équipe environ 69,4 % des sites dont le langage serveur est identifié à la mi-octobre 2026. Cette statistique ne signifie pas que tous ces sites sont vulnérables : l’exposition dépend de la version, de la configuration et des protections en place.
Pour une PME, la question dépasse le périmètre de la cybersécurité. Une intrusion sur le serveur peut entraîner une interruption de service, une défiguration du site, une manipulation de contenus ou une compromission de données, selon les droits obtenus par l’attaquant. Pour un e-commerçant, chaque heure d’indisponibilité peut se traduire par des commandes manquées, des dépenses de remédiation, une surcharge du service client et une perte de confiance. Il s’agit de risques possibles, et non de dommages déjà constatés à grande échelle.
Les entreprises dépendantes d’un prestataire d’infogérance ou d’un hébergement mutualisé doivent identifier précisément qui administre PHP. Mettre à jour WordPress, ses extensions ou son thème ne met pas nécessairement à jour le moteur PHP du serveur. Le correctif peut relever de l’hébergeur, de l’administrateur système ou d’un contrat de maintenance.
Les correctifs PHP sont disponibles : quelles versions installer ?
L’éditeur a publié des versions corrigées pour les branches encore suivies : PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 et PHP 8.5.12. Les éditeurs de distributions Linux peuvent proposer des paquets correctifs spécifiques, parfois avec des numéros de version différents en raison de corrections rétroportées. Il faut donc vérifier le bulletin de son fournisseur plutôt que de comparer uniquement les numéros.
La situation est plus délicate pour les anciennes branches. PHP 8.1 et les versions précédentes ne bénéficient plus du support de sécurité régulier du projet. Certains fournisseurs de distributions ou de maintenance longue durée peuvent néanmoins fournir des correctifs rétroportés. L’équipe PHP a aussi publié des rétroportages minimaux de code source pour les branches 7.4, 8.0 et 8.1, sans pour autant rétablir leur support standard. La migration vers une branche maintenue reste l’objectif.
Pour les responsables informatiques, les priorités sont claires : inventorier les sites et applications utilisant PHP, identifier les versions réellement exécutées sur les serveurs, sauvegarder et tester les applications, appliquer les mises à jour adaptées, puis redémarrer les services concernés et vérifier leur fonctionnement. Il faut également examiner les journaux et surveiller d’éventuels comportements anormaux.
Peut-on se protéger sans appliquer la mise à jour ?
Le CERT-EU recommande l’isolement temporaire des applications exposées lorsqu’une correction immédiate n’est pas possible. Le projet PHP décrit plusieurs mesures de réduction du risque, dont la désactivation de la fonction de suivi des téléversements de session dans certaines configurations. Mais ces contournements ne couvrent pas toutes les voies d’exploitation : aucun ne remplace l’installation d’un correctif.
Une entreprise qui ne peut pas intervenir immédiatement doit évaluer, avec son prestataire, la possibilité de restreindre l’accès public à l’application, de renforcer le filtrage au niveau du pare-feu applicatif et de placer les services sensibles sous surveillance. Cette décision suppose un arbitrage entre risque cyber et disponibilité commerciale, en particulier lorsque le site génère directement du chiffre d’affaires.
France : attention aux chiffres d’exposition qui circulent
Des relevés d’Internet présentés dans les premières heures de l’alerte ont laissé penser que la France figurait très largement en tête des équipements exposés, notamment à cause de millions de Freebox. Cette interprétation a été corrigée : selon les informations rapportées par Frandroid, Freebox OS n’exécute pas de serveur PHP ; la détection aurait confondu des fichiers portant l’extension .php avec l’utilisation effective du langage.
Il serait donc trompeur de présenter ces millions de box comme autant d’équipements vulnérables. Le risque confirmé concerne avant tout les systèmes exécutant réellement une installation PHP affectée et exposée à des requêtes malveillantes.
Un test de réactivité pour la chaîne numérique
Cette crise met en lumière un problème récurrent : une vulnérabilité dans une composante technique partagée peut obliger, en quelques heures, des milliers d’organisations à coordonner hébergeurs, prestataires, équipes de sécurité et métiers. L’enjeu ne se résume pas à installer un paquet logiciel : il faut savoir qui décide, qui intervient, comment tester la correction et comment maintenir l’activité pendant l’opération.
Pour les dirigeants, le réflexe immédiat consiste à demander au responsable informatique ou à l’hébergeur une confirmation écrite de la version corrigée installée, des sites couverts et des éventuelles exceptions. Une bonne cartographie des actifs numériques et un contrat de maintenance clair peuvent faire la différence entre un correctif appliqué dans la journée et une exposition prolongée.
Sources : équipe de sécurité PHP ; CERT-FR / ANSSI ; CERT-EU ; W3Techs ; Frandroid. Article mis à jour sur la base des correctifs annoncés le 21 octobre 2026.