Le 21 octobre à 16 heures, le projet PHP a publié en urgence les correctifs de deux failles notées 9,2 sur 10, qui permettent à un inconnu de faire exécuter ses propres commandes par un serveur web. PHP fait tourner 69,3 % des sites dont le langage serveur est connu. Le correctif existe. Reste à savoir qui peut l’installer : un site PHP sur trois tourne sur une version que le projet ne corrige plus.
J’ai suivi la journée dans les documents techniques, pas dans les dépêches. Ce qui apparaît n’est pas seulement l’histoire de deux bugs, mais celle d’une couche d’infrastructure dont dépendent boutiques, mairies et journaux, réparée le jour même puis appliquée au rythme de chacun.
- Ce que les deux failles permettent
- Une fuite a avancé le calendrier d’un jour
- Un tiers des sites PHP n’aura pas de correctif
- Exposé n’est pas vulnérable, corrigé n’est pas protégé
- Qui maintient cette couche, et qui en répond
Ce que les deux failles permettent
Le bulletin de PHP est d’une clarté rare : toutes les installations qui servent des requêtes web sont concernées. Le risque est le plus élevé pour mod_php, où une requête non authentifiée déclenche l’exploit avant le moindre code du site.
Les deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, portent sur le moteur, pas sur le site. La première exploite un dépassement de mémoire : PHP est interrompu alors que les données internes de la requête ne sont que partiellement initialisées, et le nettoyage les traite ensuite comme valides. La seconde joue sur un état global périmé. Une seule requête bien construite suffit.
Aucune mitigation n’est complète : la mise à jour est le seul choix sûr. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le CERT-FR a publié le même jour l’alerte CERTFR-2026-ALE-014, qui étend la liste des systèmes affectés à toutes les versions 5.x, 6.x, 7.x et 8.x, et recommande, pour les branches non maintenues, d’isoler puis de migrer.
Une fuite a avancé le calendrier d’un jour
La divulgation était prévue le 22 octobre, selon la société watchTowr. Le 20 octobre, un message sur Hacker News, depuis supprimé, a révélé les deux failles et le nom d’un outil censé les exploiter. PHP publiait le même jour un préavis pour une sortie le lendemain à 16 heures.
Cette accélération a un coût : administrateurs et attaquants ont reçu le même signal au même moment. Tenable rapporte que le directeur technique de Cloudflare voit des attaques précoces apparaître. Au moment où j’écris, aucune compromission de masse n’est documentée : des tentatives observées ne sont pas des milliers de sites tombés.
Un tiers des sites PHP n’aura pas de correctif
Les chiffres de W3Techs, relevés le 21 octobre, situent le parc : 65,2 % tournent sur PHP 8, 27,0 % sur PHP 7, 7,7 % sur PHP 5 et 0,1 % sur PHP 4.
La version de PHP qu’utilisent les sites qui l’emploient
Part des sites PHP par version majeure, en pourcentage. Survolez une barre pour le détail. Source : W3Techs, relevé du 21 octobre 2026.
L’arithmétique est sévère. PHP 7, 5 et 4 représentent 34,8 % des sites PHP, plus d’un sur trois. Or PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour. Les mainteneurs ont publié des rétroportages minimaux pour PHP 7.4, 8.0 et 8.1, à l’intention de ceux qui compilent eux-mêmes : un lot de sources à compiler, à ses frais, pas une mise à jour.
Les autres passent par les distributions Linux et les hébergeurs, qui ont reçu les correctifs à l’avance. Un site en mutualisé n’a souvent aucun accès au PHP qu’il exécute : l’hébergeur décide de la version et du redémarrage. Le propriétaire peut donc être vulnérable sans rien avoir à mettre à jour, et sans le savoir.
Exposé n’est pas vulnérable, corrigé n’est pas protégé
Deux confusions ordinaires circulent. Un serveur qui répond en PHP n’est pas vulnérable : un recensement mesure une exposition, pas une version, et encore moins une faille exploitable. Et mettre à jour PHP ne met pas à jour le site : le correctif du moteur ne touche ni WordPress, ni ses extensions, ni le thème. WordPress équipe 39,6 % des sites web selon W3Techs et repose entièrement sur PHP : la chaîne a deux étages, il faut les deux.
Pour un propriétaire de site, la question se pose par écrit. Quelle version de PHP mon site exécute-t-il ? Est-elle corrigée depuis le 21 octobre ? Qui applique la mise à jour, et à quelle date ? Les deux contournements du CERT-FR, couper le suivi de progression des envois et bloquer les requêtes multipart, ne couvrent qu’une des vulnérabilités : ils tiennent quelques heures. La même logique d’alerte sans contrainte avait été décrite ici à propos des frigos connectés de supermarchés, et la question de l’inventaire s’était posée après les 99 fuites de données recensées dans l’administration comme après la fuite de la Région Hauts-de-France.
Qui maintient cette couche, et qui en répond
PHP n’est pas un service public : c’est un projet libre, avec une équipe de sécurité et des contributeurs, qui n’appartient à aucun État. Le 21 octobre, la réponse à une faille critique sur 69,3 % du web est venue d’un bulletin de sécurité et d’archives à télécharger.
Je n’ai trouvé aucun inventaire public des sites français qui dépendent de PHP, ni de leur version. Le CERT-FR alerte, recommande, outille ; il n’administre pas les serveurs des entreprises, des associations et des communes.
Ce n’est pas un reproche aux mainteneurs, qui ont fait leur travail vite et bien, mais un constat sur l’organisation : la couche la plus basse du web français n’a ni plan, ni recensement, ni responsable désigné. Le jour où une faille de cette classe sera exploitée avant sa correction, personne ne pourra dire combien de sites ont été touchés.
Cette vidéo de 5 minutes 42, publiée le 21 octobre avant la sortie du correctif, explique le mécanisme tel qu’il était connu ce matin-là : deux failles du moteur, exploitables sans authentification. Elle documente la compréhension technique du moment, pas l’état des attaques ni la liste des sites touchés.
Notre lecture
Opinion de la maison, pas un fait. Ce que révèle cette journée n’est pas la gravité de deux bugs : ils sont corrigés. C’est l’absence d’inventaire. Un pays qui ignore combien de ses sites tournent sur une version abandonnée d’un langage qu’il n’a pas écrit ne maîtrise pas sa base numérique, il en loue la continuité. La souveraineté, au sens où je l’entends, est la capacité à encaisser un choc.
Et vous ? Si vous avez un site, une boutique, un blog ou le site d’une commune : savez-vous quelle version de PHP le fait tourner, et qui applique les mises à jour ? Posez la question par écrit à votre hébergeur cette semaine. La réponse, ou son absence, en dit long sur ce que vous possédez vraiment.
