Faille PHP du 21 octobre : ce qui s'est passé et où nous en sommes

Le mercredi 21 octobre, deux failles de sécurité graves ont été révélées dans PHP, le langage de programmation sur lequel fonctionne la grande majorité des sites web, dont WordPress. Vous l'avez peut-être remarqué, car une partie de la journée, les sites web hébergés chez nous étaient hors ligne. Dans cet article, nous résumons ce qui s'est passé, comment nous avons réagi et où nous en sommes aujourd'hui.

Que s'est-il passé ?

Les failles (CVE-2026-109618 et CVE-2026-109619) permettaient à des personnes non autorisées d'exécuter du code sur un serveur web. C'est à peu près le pire type de faille qui existe : un attaquant n'a besoin d'aucun mot de passe pour l'exploiter, et elle touche pratiquement l'ensemble d'internet.

Comment nous avons réagi

1. Mesure temporairemercredi 21 octobre, 10h00

   À ce moment-là, on savait seulement que deux failles graves affectaient toutes les versions de PHP, avec un score CVE de 9,2. Les détails n'étaient pas encore connus et aucun piratage réussi n'avait été signalé, même si Cloudflare, par exemple, observait un nombre croissant de tentatives. Comme les détails de la faille n'étaient pas connus, personne ne savait exactement de quoi il s'agissait ni ce qui pouvait être fait pour limiter le risque. De plus en plus d'atténuations et d'actions possibles pour limiter le risque étaient toutefois publiées. Nous les avons systématiquement mises en œuvre immédiatement, comme la désactivation de certaines fonctions PHP et la mise à jour à plusieurs reprises du pare-feu.
   À partir de 10h00, nous avons également fait tourner en continu des analyses antimalware très strictes, afin de détecter immédiatement si un script était placé quelque part sur nos serveurs ou dans les comptes de nos clients. Cela ne s'est pas produit.

2. Sites web hors lignemercredi 21 octobre, 15h15

   Bien que nous n'ayons constaté aucune tentative d'exploitation sur nos serveurs, nous avons décidé de choisir l'option la plus sûre : tout mettre hors ligne. La principale raison est que nous avions des doutes sur l'efficacité des mesures d'atténuation (solutions temporaires) qui circulaient sur internet, car personne ne pouvait confirmer qu'elles offraient une protection suffisante.
   Dans une situation présentant autant d'incertitudes et des conséquences potentiellement énormes, quelques heures d'indisponibilité sont justifiables ; prendre le risque ne l'est pas.

3. Solution officiellemercredi 21 octobre, 16h00

   Les créateurs de PHP ont publié la mise à jour officielle contenant le correctif pour les versions 8.3, 8.4 et 8.5. Il ne restait plus qu'à attendre les paquets mis à jour de CloudLinux, le fournisseur des versions de PHP sur nos serveurs.
   Au moment de la publication de la mise à jour, les détails des vulnérabilités ont également été dévoilés, ce qui a confirmé notre intuition : les mesures d'atténuation connues et les règles de pare-feu supplémentaires réduisaient certes le risque de piratage, mais cela ne suffisait pas à protéger le serveur.

4. Solution temporairemercredi 21 octobre, 19h00

   Malheureusement, il a fallu beaucoup plus de temps que nous l'espérions et l'avions prévu avant que CloudLinux ait les mises à jour prêtes. Nos échanges avec d'autres hébergeurs ont montré que nous n'étions pas les seuls surpris. Comme nous constations qu'ils n'avaient déjà pas respecté à plusieurs reprises les délais qu'ils s'étaient eux-mêmes fixés, nous avons travaillé à une solution temporaire.
   Nous avons installé nous-mêmes la version PHP 8.3.36 sur tous nos serveurs et avons temporairement basculé tous nos clients vers cette version. 90 % des sites web sont revenus en ligne entre 19h00 et 20h30. Les seuls sites qui ne sont pas revenus en ligne étaient obsolètes et ne pouvaient pas fonctionner avec une version moderne de PHP.

5. Mise à jourjeudi 22 octobre, 00h30

   Les mises à jour sont devenues disponibles et nous avons immédiatement commencé l'installation et les vérifications, serveur par serveur.

6. Résolujeudi 22 octobre, 02h30

   Tous les serveurs étaient mis à jour et tous les sites web étaient de nouveau en ligne, avec la version de PHP qu'ils utilisaient auparavant.

Nous comprenons parfaitement qu'il soit désagréable que votre site web soit inaccessible pendant un après-midi et une soirée. Cette gêne ne pèse toutefois pas face aux conséquences potentielles. Nous n'avions encore jamais dû décider de tout mettre hors ligne par précaution, mais si la même situation se reproduisait, nous ferions exactement la même chose.

Où en sommes-nous aujourd'hui ?

• Toutes les versions de PHP que nous proposons, de 5.2 à 8.5 inclus, contiennent les correctifs de sécurité pour les deux failles.
• Les quelques sites web qui fonctionnaient sur une version de PHP encore plus ancienne, pour laquelle aucun correctif n'existe, ont été basculés vers une version corrigée.
• Nous avons contrôlé les serveurs, pendant et après la faille, à la recherche de traces d'exploitation, telles que des processus PHP bloqués, des processus suspects, des fichiers téléversés et des requêtes correspondant à l'attaque connue. Nous n'avons trouvé aucune indication que la faille ait été exploitée sur nos serveurs, et aucune tentative en ce sens n'a été détectée avant notre mise hors ligne.

Mon site web est-il séparé de ceux des autres ?

Oui. Chaque formule d'hébergement fonctionne chez nous dans un environnement propre et cloisonné. PHP s'exécute sous l'utilisateur de votre formule, sans droits d'administration sur le serveur, et ne peut pas accéder aux fichiers ou bases de données d'autres clients. L'utilisation du processeur et de la mémoire est également limitée par formule. Nous ne communiquons volontairement pas publiquement davantage de détails sur notre sécurité : moins un attaquant en sait, mieux c'est.