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 ».
À lire aussi : Failles PHP – pourquoi c’est un vrai casse-tête pour l’Internet mondial
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 ».
À l’ère de l’IA, le moindre grain de poussière dans les rouages d’une divulgation coordonnée peut avoir des conséquences catastrophiques. Comme l’explique CJ Moses, « le délai entre un correctif et un exploit fonctionnel se réduit », car « l’analyse assistée par IA rend bien moins coûteux de transformer un correctif en exploit fonctionnel ». De nos jours, « un nombre croissant d’acteurs peuvent désormais agir en quelques heures, voire quelques minutes ». C’est pourquoi les diverses fuites qui ont émaillé le processus de divulgation des failles se sont rapidement soldées par une vague de cyberattaques… Cloudflare a recensé des dizaines de milliers de tentatives dans les 45 minutes après la divulgation, des centaines de milliers au bout de deux heures, puis des millions dès le lendemain.
👉🏻 Suivez l’actualité tech en temps réel : ajoutez 01net à vos sources sur Google, et abonnez-vous à notre canal WhatsApp.
