Nous sommes officiellement sans PHP. Voici ce qu'octobre nous a appris (jusqu'ici)

La semaine du 19 au 24 octobre 2026, du lundi au samedi, a apporté une série continue d'actualités sécurité sérieuses dans tout le secteur. Si vous l'avez manquée, notre revue de cette semaine en couvre le détail. En version courte : dans plusieurs cas, les attaquants ont bougé avant les correctifs.

Une semaine pareille ne nous renvoie pas à la planche à dessin, mais elle affûte les lignes qui s'y trouvent déjà. C'est une chose de tenir un principe, c'en est une autre d'observer, cas après cas, ce qui se passe là où ce principe manque. Alors, plutôt que d'énumérer des mesures techniques, nous voulons expliquer les principes selon lesquels nous travaillons, car pour vous, en tant que client, l'approche compte plus que n'importe quelle mise à jour isolée. L'un de ces principes vient d'atteindre son jalon : nous sommes désormais officiellement sans PHP.

Pourquoi corriger après coup est-il une course perdante ?

Pendant des années, le conseil standard était simple : appliquez les correctifs rapidement et tout ira bien. La tendance jouait déjà contre ce conseil. L'équipe Mandiant de Google a mesuré le temps moyen entre le moment où une vulnérabilité devient connue et son exploitation : 63 jours sur 2018 à 2019, 32 jours sur 2021 et 2022, et cinq jours en 2023, en moyenne, valeurs aberrantes exclues.

Cinq jours, c'est le chiffre de 2023, avant que les outils d'IA ne fassent partie du travail logiciel quotidien. Ce mois-ci nous a donné une mesure fraîche de la course, prise depuis trois points d'observation différents autour de la divulgation de PHP2Shell du 21 octobre 2026.

L'équipe de renseignement sur les menaces d'Amazon a observé une tentative d'exploitation de PHP2Shell le 17 octobre, quatre jours avant la divulgation publique, et indique qu'une fois l'embargo levé et le correctif publié, d'autres exploits de démonstration sont apparus en quelques heures. F5 Labs a vu les premiers balayages PHP2Shell plus de cinq heures avant la publication des deux CVE, et dans les heures qui ont suivi la divulgation, ses capteurs enregistraient des milliers de tentatives d'exploitation. Le PDG de Cloudflare, Matthew Prince, a déclaré le 22 octobre que Cloudflare avait vu des milliers de tentatives avant l'annonce, des dizaines de milliers dans les 45 minutes qui ont suivi, des centaines de milliers en deux heures, et des millions au moment où il publiait son message. Il s'agissait de tentatives, pas d'intrusions confirmées, mais elles montrent à quelle vitesse les portes étaient essayées : la fenêtre se mesure désormais en minutes et en heures, et pour certains elle s'est refermée avant même que le correctif existe.

L'exploitation avant tout correctif n'est pas une rareté non plus. En 2023, 70 % des vulnérabilités exploitées suivies par Mandiant, soit 97 sur 138, l'ont été comme zero-days, c'est-à-dire avant qu'un correctif n'existe.

Si l'exploitation peut commencer avant qu'un correctif soit disponible, et arriver en masse dans les minutes qui suivent sa publication, alors l'application des correctifs, aussi disciplinée soit-elle, ne peut pas être tout le plan. Un défenseur qui ne compte que sur elle s'engage dans une course souvent jouée avant même d'avoir commencé. Nous partons donc du principe que la course sera parfois perdue, et nous concevons en prévision de la défaite. Cette hypothèse se traduit en trois questions. Tant qu'une faille est ouverte, quelle part de nos systèmes peut être touchée ? Si quelque chose est touché, que peut-on perdre ? Et une fois qu'un correctif existe, à quelle vitesse pouvons-nous nous rétablir et combler l'écart ? Chacun de nos principes répond à l'une de ces questions, et tout ce qui suit est organisé autour d'elles.

Pourquoi retirons-nous des logiciels au lieu de colmater autour ?

Commençons par la première question : quelle part peut être touchée. Chaque organisation accumule des logiciels qui ont mal vieilli : des outils dont les mainteneurs sont passés à autre chose, des composants bloqués sur de vieilles versions parce qu'autre chose en dépend, du code que personne ne veut toucher. La réponse courante consiste à envelopper ces logiciels de contournements et de règles de pare-feu, en espérant que tout ira bien.

Nous voyons les choses autrement. Un logiciel qui ne peut pas rester à jour est retiré, pas colmaté. Nous ne le maintenons pas en vie avec des correctifs temporaires, car un correctif temporaire sur du code non maintenu est une promesse qui finira par être rompue. Soit un composant peut être mis à jour aussi longtemps que nous l'exploitons, soit il ne tourne pas du tout.

Pourquoi les contournements échouent-ils ? Parce qu'un contournement ne bloque que les failles déjà connues. Un logiciel non maintenu ne cesse pas d'avoir des faiblesses le jour où ses mainteneurs s'en vont. Chercheurs et attaquants continuent d'en trouver de nouvelles, année après année, et plus personne n'est là pour écrire les correctifs. Chaque découverte impose une règle de plus, un filtre de plus, une couche de plus boulonnée sur la précédente, et la pile devient plus fragile à chaque ajout. Tôt ou tard apparaît une faille qu'aucune couche extérieure ne peut filtrer, ou bien deux couches interfèrent entre elles, et la protection cède sans bruit. Un contournement fait gagner du temps, et sur du code abandonné il n'y a rien d'utile à faire de ce temps, car le problème sous-jacent ne sera jamais corrigé.

Repensez à la course décrite plus haut, qui se joue désormais en minutes et en heures. Face à un logiciel maintenu, la course est brutalement courte, mais au moins elle peut être courue. Face à un logiciel abandonné, il n'y a pas de course du tout, car le correctif qui devrait y mettre fin n'arrivera jamais. Écrit noir sur blanc, cela semble évident. En pratique, c'est le chemin le plus dur, puisque retirer quelque chose implique généralement de reconstruire ce qui en dépendait. Nous pensons que ce coût vaut la peine d'être payé. Un attaquant ne peut pas exploiter une faiblesse dans un système qui n'existe plus.

À quoi ressemble concrètement une petite surface d'attaque ?

Le retrait est la façon la plus radicale de réduire ce qui peut être touché. L'habitude plus large qui le sous-tend porte un nom technique : garder la surface d'attaque réduite. La surface d'attaque est une idée simple, la somme de tous les endroits où un attaquant pourrait essayer une clé dans une serrure. Chaque service exposé, chaque bibliothèque tierce, chaque plugin est une serrure de plus à défendre. Notre définition d'une bonne sécurité commence ici : le code le plus solide est celui que vous n'exécutez pas, et les données les plus sûres sont celles que vous n'avez jamais stockées.

Réfléchissez à ce qu'est réellement une bibliothèque tierce ou un plugin. Quand un développeur en intègre un, il fait confiance à un inconnu, souvent un bénévole non rémunéré, pour garder ce code sûr aussi longtemps qu'il tourne. La bibliothèque a besoin de ses propres mises à jour, de ses propres correctifs de sécurité, de son propre mainteneur attentif. Si ce mainteneur se désintéresse, change de travail ou cesse simplement de répondre, le code continue de fonctionner, mais plus personne ne le surveille. Une faille découverte après ce point reste ouverte pour de bon, ce qui est le problème de l'abandon de la section précédente arrivant par une porte dérobée. Multipliez cela par les nombreux composants dont dépend une application typique, et le tableau devient clair. Chaque dépendance est une petite promesse faite par quelqu'un que vous n'avez jamais rencontré, et certaines de ces promesses expirent en silence. En exécuter moins, c'est devoir sa sécurité à moins d'inconnus.

Les systèmes sur lesquels vous vous connectez, par lesquels vous payez et auxquels nos applications s'adressent sont écrits en Go. PHP a disparu, et avec lui la longue traîne de bibliothèques, de plugins et de dépendances que les applications PHP ont tendance à traîner derrière elles.

Nous avons choisi Go pour nos systèmes les plus critiques parce qu'il répond au problème des dépendances au niveau du langage. Go est sûr en mémoire : le langage gère la mémoire à la place du programmeur, ce qui élimine toute une classe de bugs comme les dépassements de tampon, et la CISA (l'agence américaine de cybersécurité) classe Go parmi les langages à sécurité mémoire dans The Case for Memory Safe Roadmaps. Cette classe est plus vaste qu'il n'y paraît : le projet Chromium constate qu'environ 70 % de ses bugs de sécurité graves sont des problèmes de sécurité mémoire. La bibliothèque standard de Go couvre une grande partie de ce dont un service web a besoin, y compris la cryptographie, si bien qu'un service Go nécessite moins de paquets tiers, donc moins de ces promesses d'inconnus. La cryptographie y est prise suffisamment au sérieux pour que le module de cryptographie de Go soit validé selon la norme FIPS 140-3 du gouvernement américain, certificat CMVP #5247. Et quand une faille apparaît malgré tout dans l'écosystème au sens large, l'équipe sécurité de Go tient à jour une base de données de vulnérabilités, et son outil govulncheck ne signale que les vulnérabilités présentes dans le code qu'un programme appelle réellement, ce qui garde les alertes peu bruyantes et exploitables.

Cela compte, vu l'ampleur et l'âge des déploiements PHP. W3Techs rapporte que PHP est utilisé par 69,2 % de tous les sites web dont il connaît le langage côté serveur, avec 26,6 % des sites PHP encore sous PHP 7 et 7,7 % sous PHP 5, mesure effectuée le 27 octobre 2026. Le projet PHP lui-même prend en charge chaque branche de version pendant deux ans de corrections de bugs et de sécurité, puis deux ans de plus pour les seuls correctifs de sécurité critiques. PHP 7 et PHP 5 ont dépassé tout cela. Une large part du web tourne sur du code que ses propres créateurs ne protègent plus, c'est-à-dire la course perdante de la première section, mais engagée volontairement.

Notre site web est constitué de pages statiques construites à l'avance, sans code côté serveur pour les générer lors de votre visite. Une page qui n'est qu'un fichier offre très peu de prise à l'attaque. À la question de savoir quelle part peut être touchée, voici notre réponse : aussi peu que possible.

Quelles données conservons-nous à votre sujet ?

Une surface réduite limite les moyens pour un attaquant d'entrer. La deuxième question porte sur ce qu'il trouverait si, un jour, l'un d'eux entrait malgré tout. Notre réponse consiste à rendre la trouvaille aussi inintéressante que possible : moins de données, conservées moins longtemps.

Nous ne demandons que ce qui est nécessaire au fonctionnement d'un compte. Notre politique de confidentialité l'énumère clairement : un nom d'utilisateur, une adresse e-mail, un mot de passe chiffré et l'adresse IP utilisée à l'inscription. Les paiements passent par des prestataires de paiement tiers, donc les données de votre carte vivent chez des spécialistes dont tout le métier est de les protéger, pas chez nous.

Nous resserrons aussi ce qui se passe au fil du temps. Les vieux comptes inutilisés seront supprimés automatiquement. Des données qui n'existent pas ne peuvent pas fuiter, ne peuvent pas être volées et ne peuvent pas être exigées. Un compte que vous avez abandonné il y a des années ne devrait pas traîner comme un passif portant votre nom. Si la course est un jour perdue de notre côté de la clôture, le butin sur la table doit être aussi petit que nous pouvons le rendre.

La même logique s'applique au-delà de nous, car d'autres entreprises perdent aussi des courses. Beaucoup des fuites dont les gens sont victimes se produisent chez des boutiques, des forums et des services auxquels ils se sont inscrits il y a longtemps. C'est pourquoi nous proposons des alertes de fuite de données : notre Data Breach Scanner vérifie si votre adresse e-mail figure dans des fuites de données connues et vous envoie un e-mail si c'est le cas, pour que vous puissiez changer vos mots de passe avant que la fuite soit exploitée.

Que se passe-t-il si quelque chose casse malgré tout ?

La troisième question comporte deux volets : se rétablir, et combler l'écart. Le rétablissement d'abord. Une bonne planification de la sécurité suppose des mauvais jours. Le matériel tombe en panne, les fournisseurs changent, et parfois le bon choix est tout simplement de tourner le dos à une partie de l'infrastructure.

Nos systèmes sont construits de façon à pouvoir être recréés ou déplacés ailleurs si nécessaire. Pour vous, cela signifie qu'une panne, ou un emplacement qui ne répond plus à nos exigences, n'a pas à se transformer en longue interruption, car le système concerné peut être reconstruit ou déplacé. Si nous concluons un jour qu'un environnement n'est plus assez bon, nous pouvons le quitter plutôt que de négocier avec lui.

La résilience n'est pas une qualité spectaculaire. Elle se manifeste surtout par des choses qui continuent de fonctionner, et dans ce cadre, c'est elle qui empêche une manche perdue de devenir une saison perdue.

À quelle vitesse les correctifs atteignent-ils nos systèmes ?

L'autre volet de la troisième question, c'est la vitesse. Rien de ce qui précède ne supprime le besoin de corriger ; cela change ce que la correction doit porter. Avec une surface réduite et des logiciels à jour, appliquer un correctif est une routine plutôt qu'un projet.

Notre règle est simple : les mises à jour partent dès que les correctifs existent. Les mesures d'octobre expliquent pourquoi. Quand les tentatives d'exploitation arrivent dans les minutes et les heures qui suivent la publication d'un correctif, et parfois avant même qu'il existe, un correctif qui attend ne protège personne. Nous traitons un correctif publié comme un coup de pistolet de départ. L'intervalle entre l'existence d'un correctif et son application est la seule partie de la course qu'un défenseur contrôle entièrement, c'est donc celle que nous refusons de céder.

Et comme notre pile logicielle est petite, il y a tout simplement moins à corriger, et c'est là que les trois questions se rejoignent : moins il y a à toucher, plus vite l'écart se referme.

Mises côte à côte, les questions et les principes qui y répondent ressemblent à ceci :

Qu'est-ce que tout cela signifie pour vous ?

Cela signifie que les trois questions ont des réponses tangibles. Moins de code se tient entre vous et votre compte, donc il y a moins d'endroits où quelque chose peut mal tourner. Moins de vos données existent, donc même le pire des cas en expose peu. Et nos systèmes peuvent être reconstruits, donc un mauvais jour pour nous n'a pas à devenir une longue interruption pour vous.

Nous serons honnêtes sur la limite de tout cela. La course par laquelle nous avons commencé ne peut pas être gagnée de façon fiable, ni par nous ni par personne, car des failles sont parfois exploitées avant que quiconque sache qu'elles existent, et aucune architecture ne change cela. Aucun fournisseur ne peut promettre un risque nul, et quiconque le fait vend de la confiance plutôt que de la sécurité. Ce que nous pouvons promettre, c'est la forme d'une perte : peu de portes d'entrée, peu à prendre, et un retour rapide. Nous ne pouvons pas garantir de gagner chaque manche de la course. Nous avons construit pour qu'en perdre une vous coûte aussi peu que possible, et nous pensons que cette promesse, tenue avec constance, vaut plus qu'une promesse audacieuse qui ne peut pas l'être.

La sécurité est aussi un effort partagé. La configuration la plus solide que nous puissions bâtir profite encore de bonnes habitudes de votre côté, alors si vous cherchez des mesures concrètes, commencez par notre guide sur comment renforcer votre sécurité en ligne. Et si vous choisissez un VPN, chez nous ou chez n'importe qui d'autre, demandez au fournisseur comment il pense, pas seulement ce qu'il vend. La réponse en dit long sur la façon dont se passeront vos semaines calmes, et les semaines agitées.