Failles PHP du 21 octobre : protégés le jour même, grâce à des choix faits bien avant

Le 21 octobre, deux failles critiques ont touché PHP, le langage qui fait tourner une grande partie du web. Le jour même, notre serveur était protégé. Mais la vraie protection avait été choisie bien avant.

Dans cet article, nous revenons sur ce qui s'est passé, sur la façon dont nous avons réagi, et surtout sur ce qui nous a permis de réagir vite. Car face à une faille de sécurité, la rapidité ne s'improvise pas le jour J : elle se prépare des mois, parfois des années, à l'avance.

Que s'est-il passé le 21 octobre ?

Le 21 octobre, les mainteneurs de PHP ont publié en urgence des correctifs pour deux failles critiques, référencées CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 sur l'échelle de gravité CVSS.

Ces deux failles permettent une exécution de code à distance : dans les bonnes conditions, une personne extérieure peut faire exécuter ses propres instructions par le serveur qui héberge le site. C'est la catégorie de failles la plus redoutée, parce qu'elle ouvre la porte à tout le reste.

Les correctifs ont été publiés pour les versions encore maintenues de PHP (8.2, 8.3, 8.4 et 8.5). Pour les branches plus anciennes, comme PHP 7.4 ou 8.1, aucune version officielle n'a été publiée : elles ne sont plus suivies par l'équipe de PHP.

Pourquoi une faille PHP concerne-t-elle votre site ?

Parce que si votre site tourne sous WordPress, PrestaShop, Drupal ou un développement sur mesure en Symfony ou Laravel, c'est PHP qui l'exécute à chaque visite.

Une faille dans PHP n'est pas une faille dans votre thème ou dans une extension mal codée. Elle touche le moteur lui-même. Un site parfaitement conçu, à jour côté CMS, reste exposé si la version de PHP qui le fait tourner n'est pas corrigée. C'est précisément ce qui rend ce type d'alerte sérieux : il ne suffit pas d'avoir un « bon site », il faut un environnement tenu.

Comment avons-nous réagi le jour même ?

Nous avons agi en deux temps : une mesure de protection immédiate sur l'ensemble du serveur, puis l'installation des versions corrigées dès qu'elles ont été disponibles.

• ›Lecture des bulletins de sécurité et identification de toutes les versions de PHP présentes sur notre serveur.
• ›Application, sur chacune de ces versions, du contournement recommandé : la désactivation du réglage PHP impliqué dans l'exploitation des failles, suivie du redémarrage des services et d'une vérification.
• ›Installation, le jour même, des versions corrigées de PHP 8.2 à 8.5.
• ›Deux jours plus tard, mise à jour des autres branches présentes sur le serveur, puis contrôle des sites un par un.

Concrètement, le contournement a fermé la porte avant même que les mises à jour officielles ne soient installées. Les correctifs sont ensuite venus remplacer cette protection d'urgence par une protection durable.

Pourquoi la vraie protection avait-elle été choisie bien avant ?

Parce qu'on ne peut réagir en quelques heures que si l'on sait exactement ce qui tourne, où, et que l'on a la main pour agir sans attendre personne.

Le 21 octobre, rien de ce qui nous a fait gagner du temps n'a été décidé ce jour-là. Tout reposait sur des choix faits bien en amont :

• ›Un hébergement maîtrisé : les sites que nous maintenons sont sur notre propre serveur. Pas de ticket à ouvrir chez un hébergeur mutualisé, pas de file d'attente.
• ›Un inventaire tenu : nous savons quelle version de PHP fait tourner chaque site. Le jour d'une alerte, on ne cherche pas, on agit.
• ›Des versions maintenues : un site qui tourne sur une branche PHP encore suivie reçoit le correctif officiel le jour même. Un site resté sur une branche abandonnée, lui, ne peut compter que sur des mesures de contournement.
• ›Une maintenance contractualisée : la mise à jour fait partie du service, elle n'attend ni un devis ni une validation en urgence.

C'est aussi pour cela que nous poussons nos clients à faire évoluer les sites qui tournent encore sur de vieilles versions de PHP. Ce n'est pas un caprice technique : c'est ce qui fait la différence entre un correctif installé en quelques heures et une protection de fortune en attendant mieux.

Que risque un site qui n'est plus maintenu ?

Il reste exposé tant que personne ne s'en occupe, et il n'a pas besoin d'être visé personnellement pour être attaqué.

Dès qu'une faille est rendue publique, des robots parcourent le web en continu à la recherche de serveurs non corrigés. Ils ne choisissent pas leurs cibles : ils testent tout ce qu'ils trouvent. Une petite entreprise est donc aussi exposée qu'un grand groupe, avec souvent moins de moyens pour s'en apercevoir.

Les conséquences sont rarement spectaculaires au début, et c'est ce qui les rend dangereuses :

• ›Des pages modifiées ou des redirections vers des sites frauduleux, qui ruinent la confiance de vos visiteurs.
• ›Un programme de minage de cryptomonnaie installé en silence, qui ralentit le serveur pendant des mois.
• ›Une fuite de données personnelles, avec les obligations qui en découlent au titre du RGPD.
• ›Un site signalé comme dangereux par Google, et un référencement qui s'effondre.

Comment savoir si votre site est concerné ?

Le plus simple est de poser quelques questions précises à votre prestataire ou à votre hébergeur.

• ›Quelle version de PHP fait tourner mon site, et est-elle encore maintenue ?
• ›Les correctifs du 21 octobre ont-ils été appliqués, et à quelle date ?
• ›Qui surveille les bulletins de sécurité, et dans quel délai intervient-il ?
• ›Mon site est-il compatible avec une version récente de PHP, et sinon, que faudrait-il faire ?

Si personne n'est en mesure de répondre clairement, c'est déjà une réponse. Cela ne veut pas dire que votre site a été attaqué, mais que personne ne serait en mesure de réagir vite le jour où cela arriverait.

La maintenance d'un site, une dépense ou une assurance ?

C'est une assurance, dont on mesure la valeur le jour où elle sert.

La plupart du temps, une bonne maintenance ne se voit pas : les mises à jour passent, les sauvegardes tournent, le site répond. Le 21 octobre en est l'illustration. Pour nos clients, il ne s'est rien passé, et c'est exactement le but. Le travail avait été fait avant.