Failles PHP : le web invisible a besoin d’une mise à jour
Une grande partie du web repose sur un moteur que l’on ne voit jamais. Deux failles critiques rappellent ce qui se joue derrière les pages qui s’affichent.
Derrière la page qui s’affiche, qui s’occupe du moteur ?
Le titre a de quoi faire lever les yeux : deux failles critiques, un langage présent dans une énorme partie du web, et une mise à jour urgente. Mon premier réflexe serait de regarder si les sites s’ouvrent encore. Mauvais indicateur : une page peut très bien s’afficher pendant que le moteur qui la fabrique attend son correctif.
L’alerte PHP du 21 octobre 2026 me ramène à cette partie d’Internet que je regarde rarement. Pas les boutons, les couleurs ou les articles. Les couches qui permettent à tout cela d’exister — et les personnes qui doivent les entretenir quand une faille apparaît.
La façade n’est pas le moteur
PHP sert notamment à exécuter du code sur un serveur pour préparer ce que reçoit le navigateur. On peut ainsi utiliser un site sans jamais voir le nom du langage qui travaille derrière. Comme au restaurant : le menu ne donne pas la marque du four. Heureusement, d’ailleurs.
Des applications comme WordPress ou Drupal reposent sur PHP. Mais l’application, ses extensions et le moteur PHP restent des composants différents. Une mise à jour du premier ne remplace pas automatiquement celle du second. Le petit voyant rassurant « tout est à jour » peut donc répondre à une question plus étroite que celle qu’on lui pose.
Le CERT-FR a publié son alerte le 21 octobre, après une communication de PHP la veille. Les correctifs annoncés pour l’après-midi sont désormais disponibles. Il ne s’agit donc plus simplement de se préparer à leur arrivée, mais de vérifier leur déploiement.
Ce que les deux failles permettent
Les deux vulnérabilités portent les références CVE-2026-109618 et CVE-2026-109619. L’équipe PHP les classe comme critiques, avec une note CVSS de 9,2 sur 10. Ce score exprime une gravité technique ; ce n’est ni une probabilité de piratage de son propre site, ni un compteur de victimes.
Les avis de sécurité décrivent deux problèmes de mémoire. Le premier concerne la gestion d’un manque de mémoire qui peut laisser des données internes dans un état invalide. Le second concerne un état interne conservé trop longtemps, alors que la mémoire à laquelle il renvoie a déjà été libérée. Dans certaines conditions, ces erreurs ouvrent la voie à l’exécution de code à distance sans authentification.
Autrement dit, le danger ne suppose pas nécessairement de posséder un compte administrateur. Dans le cas démontré avec Apache et son module PHP, l’attaque peut intervenir avant même que le code de l’application commence à s’exécuter. Une application soigneusement écrite ne suffit donc pas à réparer le moteur qui la précède.
Le périmètre ne se limite pas à ce module Apache : PHP demande aussi de mettre à jour les installations web utilisant notamment PHP-FPM, FrankenPHP ou LiteSpeed. Les conditions et les démonstrations ne sont toutefois pas identiques pour chaque configuration. Éviter une généralisation sur la facilité d’attaque n’enlève rien à l’urgence du correctif.
Les « 70 % du web » demandent une précision
Le chiffre impressionne, mais son dénominateur compte. Au 21 octobre, W3Techs mesure 69,3 % parmi les sites dont il connaît le langage côté serveur. Ce n’est pas une mesure de tous les sites sans exception, encore moins le pourcentage de sites déjà compromis.
Dans ce même relevé, les versions 7 et 5 représentent respectivement 27 % et 7,7 % des sites détectés comme utilisant PHP. Ces proportions décrivent un parc logiciel, pas un audit individuel de sa protection : des fournisseurs peuvent intégrer des correctifs à leurs propres paquets. Elles montrent néanmoins pourquoi une alerte sur une vieille couche logicielle ne disparaît pas avec l’annonce d’une nouvelle version.
La distinction n’est pas une manière de diminuer le problème. Une technologie aussi répandue crée un enjeu collectif évident. Mais trois questions restent différentes : est-elle utilisée, l’installation est-elle vulnérable, a-t-elle été compromise ? Les confondre produit de l’inquiétude, pas un meilleur diagnostic.
Je trouve le chiffre plus utile quand il conduit à chercher qui maintient réellement le service. Beaucoup moins quand il transforme Internet en immense tableau rouge où tout serait déjà perdu.
La bonne mise à jour, au bon endroit
Les versions correctives publiées par PHP le 21 octobre sont les suivantes : 8.2.35, 8.3.36, 8.4.27 et 8.5.12, chacune pour sa branche. Il faut appliquer le correctif approprié, ou le paquet corrigé confirmé par le fournisseur de sa distribution. Être simplement « en PHP 8 » n’est pas une réponse suffisante.
Pour un site hébergé, la question concrète à poser au prestataire tient en peu de mots : quelle version corrigée traite actuellement les requêtes de ce site, et le déploiement est-il terminé ? Une sauvegarde et une vérification de compatibilité restent utiles ; elles doivent accompagner l’intervention, pas devenir une raison de laisser indéfiniment une version exposée en place.
Une commande comme php -v renseigne le programme appelé dans le terminal. Ce n’est pas, à elle seule, la preuve que le site web utilise ce même programme. Le manuel distingue plusieurs interfaces d’exécution, dont la ligne de commande et les interfaces des serveurs web. Il faut contrôler le service réellement concerné, par les outils d’administration appropriés, sans exposer publiquement ses informations techniques.
Les anciennes branches demandent davantage d’attention. PHP 8.1 et les versions antérieures ne sont plus maintenues par le projet. Des correctifs rétroportés existent selon les fournisseurs ; PHP fournit aussi exceptionnellement des adaptations en code source pour 7.4, 8.0 et 8.1. Ce n’est pas un retour à un support ordinaire, ni une invitation à bricoler une migration sans accompagnement.
Le CERT-FR recommande d’isoler les équipements concernés qui restent sur des versions non maintenues, puis de migrer vers une version maintenue et corrigée. Les réglages provisoires ne constituent pas une protection complète contre les deux failles. Un pare-feu ou une option désactivée ne doit pas se transformer en certificat de sécurité imaginaire.
Entre « ça marche » et « c’est entretenu »
Une fois le correctif installé, deux autres questions subsistent : les processus utilisent-ils bien la version corrigée, et faut-il rechercher les signes d’une intrusion antérieure ? Corriger une porte d’entrée ne démontre pas que personne ne l’a empruntée. En cas de soupçon, l’analyse des journaux et l’intervention du responsable sécurité sont un autre travail que la simple mise à jour.
Ce qui me frappe, c’est notre manière de regarder un site comme un objet livré une fois pour toutes. On discute longtemps de son apparence, puis beaucoup moins de la maintenance qui le rend durable. Pourtant, le visiteur ne voit généralement pas si le moteur a été suivi avec soin.
Cette alerte n’oblige pas à déclarer un langage entier coupable, ni à promettre qu’un autre n’aura jamais de faille. Elle oblige à rendre visible une responsabilité : savoir quelles briques on utilise, qui reçoit les alertes et qui peut intervenir quand elles arrivent.
Je pensais regarder une nouvelle inquiétante sur PHP. Je me retrouve avec une question presque administrative, mais autrement plus concrète : quand notre site dit encore « bonjour » au visiteur, savons-nous qui s’occupe de ce qui se passe derrière ?