« Un échec » cuisant pour la cybersécurité : pourquoi les failles PHP ont plongé une partie d’Internet dans le noir




Des préfectures aux hôpitaux en passant par des opérateurs, des centaines de sites se sont retrouvés dans le noir cette semaine à cause de deux failles critiques dans PHP. Aux origines de ce chaos, on trouve un protocole de sécurité qui s’est mal passé. Des fuites ont en effet mené à une véritable course contre la montre… Retour sur le fiasco « structurel » qui a secoué Internet cette semaine.

Quand une faille de sécurité est découverte, le monde de la cybersécurité suit un protocole bien précis : la « divulgation coordonnée ».

Une fois la vulnérabilité débusquée, le correctif est préparé dans le plus grand secret par les développeurs.

Pour éviter que des pirates exploitent la faille dans le cadre de cyberattaques, seul un petit cercle d’éditeurs et d’hébergeurs est prévenu à l’avance de l’arrivée d’une mise à jour.

L’information est gardée la plus secrète possible, surtout si la défaillance est critique.

À une date déterminée en amont, tout est rendu public d’un seul coup.

Tout le monde doit alors se dépêcher d’installer la mise à jour pour prendre les pirates de court. Pour les failles PHP2Shell qui ont secoué tout Internet, la divulgation publique était prévue le 22 octobre… mais rien ne s’est passé comme prévu.


Une faille trop complexe… sauf pour l’IA

L’histoire de la découverte des failles PHP2Shell commence deux ans plus tôt, en 2024.

Cette année-là, un développeur de PHP repère les premiers signes d’une défaillance lors d’un audit.

À ce moment-là, les risques sont jugés théoriques.

Les tentatives de correctif s’enlisent, faute de moyens du côté de la PHP Foundation.

Il faudra attendre l’été 2026 pour que des chercheurs prouvent qu’on peut réellement s’en servir pour prendre le contrôle d’un serveur.

Selon les chercheurs de Wiz, qui ont débusqué les failles à l’aide de l’IA, les vulnérabilités n’étaient pas particulièrement faciles à exploiter.

En fait, l’exploitation nécessitait « une chaîne d’étapes complexe, à la limite de ce que des chercheurs humains pouvaient réaliser ».

Il aura fallu que l’intelligence artificielle entre en scène pour que les choses changent, et que la faille soit prise un peu plus au sérieux.

La fondation PHP admet que ce retard fut « un échec structurel, dû au processus de décision de l’équipe de sécurité et à son manque de ressources ».


Exploitation et fuite

Une fois que Wiz s’est penché sur la faille, un correctif a été rapidement mis sur pied.

Comme évoqué plus haut, celui-ci devait être annoncé dans la journée du 22 octobre.

Quatre jours avant la date prévue, le 18 octobre, Amazon repère une première tentative d’exploitation de la brèche de PHP.

En théorie, aucun pirate n’était pourtant au courant de la vulnérabilité.

Pour le moment, « on ne sait toujours pas comment l’acteur a obtenu les informations avant la divulgation », indique CJ Moses, responsable sécurité d’Amazon.

Deux jours plus tard, un utilisateur du forum Hacker News publie les identifiants officiels des deux vulnérabilités (CVE-2026-109618 et -109619), qui étaient censés rester secrets encore pendant 48 heures.

Le message, rapidement supprimé par son auteur, précise même que les vulnérabilités n’ont pas encore été divulguées.

Face aux fuites, l’équipe de sécurité de PHP sort du silence dans la journée du 21 octobre.

La fondation confirme travailler sur les correctifs, corrige les fausses informations qui circulent, et se réserve le droit de publier les mises à jour plus tôt que prévu.

Les autorités lancent des alertes d’urgence. Le correctif est finalement publié, un jour avant la date initiale prévue.


Un correctif diffusé 6 heures trop tot

Ce n’est pas tout. L’entreprise Chainguard, qui avait reçu le correctif en avance pour préparer ses clients, a commis une bourde.

La société a en effet mis en ligne des versions corrigées de PHP avant la date prévue.

Ces correctifs ont permis aux cybercriminels de repérer où se trouvent les failles, ouvrant la voie à des cyberattaques.

« N’importe quel attaquant pouvait désormais étudier le correctif sous forme binaire pendant que tous les autres utilisateurs de PHP attendaient encore la publication », déplore la PHP Foundation, soulignant que des semaines de coordination ont été réduites à néant.
Le 22 octobre, « plus de six heures avant la publication coordonnée, Chainguard a rompu l’embargo de manière unilatérale ».

Moins d’une heure plus tard, les chercheurs d’ELLIO ont enregistré les premiers signaux d’attaques.

Le PDG de Chainguard, Dan Lorenc, explique avoir « pris la décision de les sortir plus tôt quand des tactiques d’exploitation sont apparus dans la nature »

Je voulais partager ce qui s'est passé avec l'embargo PHP, notre rôle dans celui-ci et mon processus de décision hier soir pour expédier les versions corrigées plus tôt. Tout d’abord, la Fondation PHP et les responsables ont fait un travail incroyable ici, dans une situation très stressante. Je suis désolé que ma décision ait entraîné encore plus de stress pour eux.

Nous avons d'abord appris qu'il y avait quelque chose à venir en PHP vendredi dernier par l'un des chercheurs originaux qui ont découvert ce problème. Cette nuit-là, nous avons pu découvrir indépendamment le même problème en utilisant notre harnais et un modèle frontière avec une invite de base « trouver les mauvaises vulnérabilités dans PHP ».

Nous avons été entièrement lus samedi et avons confirmé que certaines de nos conclusions correspondaient à celles du rapport initial, et avons travaillé pour aider à tester les correctifs.

Les informations de lundi ont commencé à fuir et nous avons suivi le processus de divulgation coordonnée. Mardi soir, les rumeurs se sont encore multipliées et plusieurs autres fournisseurs de sécurité participant au processus ont confirmé avoir vu des exploits dans la nature.

Après avoir parlé à plusieurs autres chercheurs lors d'un appel vidéo, j'ai appelé pour envoyer les correctifs et j'ai immédiatement informé le groupe, en suivant les directives du processus coordonné de divulgation des vulnérabilités pour la publication après preuve d'exploits dans la nature. Cette décision était basée sur la facilité avec laquelle nous avons pu découvrir indépendamment la vulnérabilité et créer un exploit, sur la quantité d'informations déjà disponibles sur les vulnérabilités et les correctifs à venir, et sur les preuves partagées sur les exploits actifs dans la nature.

Nous avons publié des artefacts construits et les avons rendus accessibles au public pour tous - pas seulement pour nos clients - tard hier soir, heure de l'Est. Ce matin, la Fondation PHP a publié sa déclaration et n'était évidemment pas d'accord avec ma décision. Ce truc est nul, et la divulgation des vulnérabilités pour des vulnérabilités comme celle-ci se déroule rarement sans problème.

Nous formons tous une seule équipe ici, essayant de minimiser les dommages causés aux utilisateurs finaux par les attaques. Nous travaillons chaque jour sur des centaines de divulgations comme celle-ci, et ce depuis trois mois, à la fois pour des vulnérabilités que nous avons découvertes nous-mêmes et avec des partenaires. Notre politique pour tout cela est et a été de faire ce qui contribue à protéger le plus grand nombre de personnes. J'en ai parlé il y a quelques mois sur notre blog.

Nous n’y parviendrons pas toujours et tout le monde ne sera pas d’accord avec nos décisions, mais tel est toujours notre objectif.

C'est malheureusement la nouvelle norme pour l'industrie, et nous allons devoir travailler ensemble en équipe pour avoir une chance de sécuriser notre infrastructure critique suffisamment rapidement pour empêcher les attaquants de causer de réels dommages.