On corrige ce qui fait du bruit

J'ai passé cette semaine en Italie, dans un ashram, en retraite spirituelle avec ma famille. C'est la semaine que le secteur de la cybersécurité a choisie pour se réveiller d'un coup et déclarer un bain de sang de CVE. En quelques jours, les clés d'une autorité de certification indienne se sont révélées calculables en moins d'une seconde, PHP et Node.js ont corrigé le même mercredi deux failles qui donnent la main sur un serveur, et une faille de pare-feu corrigée depuis mai est réapparue entre les mains de groupes de rançongiciels. La France, elle, digérait encore l'attaque des chambres froides de ses supermarchés.

Le fait le plus instructif de la semaine ne figurait dans aucun avis de sécurité. Il tenait au comportement des organisations. Pour la faille PHP, des équipes contre lesquelles nous nous battons d'habitude pour obtenir une mise à jour l'ont faite sans discuter, ont demandé à pouvoir la faire et ont réclamé des conseils. Les objections habituelles avaient disparu. Quand on veut, on peut. Ce qui manque le reste du temps tient en un mot, la volonté, et cette semaine a montré ce qui la déclenche : le bruit, bien plus que la gravité.

PHP2Shell, la faille qui a eu droit à toute l'attention

PHP2Shell méritait son bruit. Les deux failles touchent le moteur PHP lui-même, qui fait tourner une grande partie du Web, de WordPress aux portails des collectivités, et permettent à un attaquant sans aucun compte d'exécuter son propre code sur le serveur. Notées 9,2 sur 10, elles ont été exploitées avant même d'être annoncées : les leurres qu'Amazon dispose sur Internet ont capté une tentative le 17 octobre, quatre jours avant la publication des correctifs. Le 23 octobre, Unit 42, l'équipe de recherche de Palo Alto Networks, décrivait une intrusion dans un organisme public européen. L'attaquant, une IA qui enchaînait elle-même les étapes, avait récupéré mots de passe et secrets de double authentification, puis visé l'annuaire qui gère tous les comptes de l'organisation, le tout en moins de deux heures. Au moins un gouvernement européen a coupé son site par précaution.

Le tri, lui, a été approximatif. Le chiffre le plus repris de la semaine, plus de 22,6 millions de serveurs « potentiellement vulnérables », compte ceux qui exécutent PHP sans rien dire de ceux qu'on peut réellement compromettre. Red Hat ne classe d'ailleurs la faille qu'en « importante » sur ses systèmes, où la configuration la plus répandue rend l'exploitation difficile en pratique. Tout le monde a pourtant reçu la même alerte rouge, celle que déclenche une faille dotée d'un nom, d'une note au-dessus de 9 et d'un communiqué de chaque grand éditeur. C'est précisément ce qui a manqué, le même jour, à une faille tout aussi dangereuse.

Node2Shell, le même jour, sous une autre étiquette

Le 21 octobre, Node.js, l'environnement qui fait tourner JavaScript côté serveur, corrigeait lui aussi une faille de son décodeur de compression qui permet, selon le projet lui-même, d'exécuter du code à distance. Les chercheurs l'ont baptisée Node2Shell, en écho évident à sa voisine. La conséquence est identique, et Node.js l'a pourtant classée « élevée » plutôt que « critique ». Elle a suscité peu de réactions, et ce mot y est pour beaucoup : dans la plupart des organisations que je connais, une faille critique se corrige en quelques jours, une faille élevée en plusieurs semaines. Aucune attaque n'avait été signalée le 24 octobre, alors que des preuves de concept circulaient déjà, et les versions 20 et antérieures de Node.js ne seront jamais corrigées.

Ce silence inquiète d'autant plus que Node.js est devenu le socle d'une bonne partie de ce que produit l'IA. Les générateurs d'applications du vibe coding, où l'on décrit une application en langage naturel et où un modèle l'écrit, livrent par défaut du React et du Next.js, qui tournent sur Node.js, parce que les modèles ont vu plus de ce code que de tout autre. Une partie des applications mises en ligne ces derniers mois l'a donc été par des personnes qui n'ont jamais choisi Node.js, ignorent quelle version tourne sur leur serveur et ne liront jamais un avis de sécurité. Une faille étiquetée « élevée » dans un environnement dont l'exploitant ignore l'existence ne déclenche rien du tout.

Une autorité de certification dont une clé valait 4 se plaint du bruit

Node2Shell a manqué de bruit à cause d'une étiquette. L'affaire eMudhra en a manqué alors qu'elle touchait plus profond encore, au mécanisme qui permet de faire confiance à un site ou à un logiciel. Une autorité de certification délivre les certificats grâce auxquels navigateurs, applications et équipements vérifient qu'ils s'adressent au bon serveur, ou que le logiciel qu'ils installent vient bien de son éditeur. Celui qui détient sa clé privée peut émettre un certificat accepté pour n'importe quel domaine et s'intercaler dans une communication sans déclencher d'alerte, ou signer un logiciel malveillant au nom d'un éditeur légitime.

Le samedi 17 octobre, un chercheur a prouvé à Google et à Mozilla que les clés privées de huit autorités de certification intermédiaires de l'indien eMudhra se recalculaient en moins d'une seconde à partir des certificats publics. L'une valait 4, les sept autres étaient des nombres inférieurs à 256. Générées en avril 2025, elles avaient passé deux audits indépendants et bénéficiaient depuis dix-huit mois de la confiance des grands navigateurs, qui les ont bloquées en quelques heures. Pour le reste, il n'existe aucun tableau de bord. Une foule de logiciels et d'équipements embarquent leur propre liste d'autorités de confiance, figée dans des conteneurs et des appareils que personne ne reconstruit. Aucun usage malveillant des clés n'avait été constaté au 21 octobre.

Les retombées médiatiques sont restées minimes, ce qui n'a pas empêché eMudhra de s'en plaindre. En annonçant le 22 octobre son retrait du marché mondial des certificats web, une activité qui pèse selon son président environ 1 % de son chiffre d'affaires, l'entreprise a jugé l'amplification sur les réseaux sociaux hors de proportion, et le ministère indien des Technologies de l'information a dénoncé des comptes alarmistes. Une autorité de certification dont une clé valait 4 reproche donc au bruit d'exister, alors qu'il est le seul signal capable de faire mettre à jour les équipements oubliés.

Corrigée en mai, exploitée en octobre par des rançongiciels

Trois jours avant la plainte d'eMudhra, une faille de pare-feu montrait ce que coûte l'absence de bruit. Elle touche le VPN des pare-feux de Palo Alto Networks, la porte par laquelle les salariés en télétravail entrent dans le réseau de leur entreprise, et permet de l'ouvrir sans identifiants. Le correctif existe depuis mai, l'agence américaine de cybersécurité la signalait comme exploitée dès le 13 mai, et les premières intrusions ont été observées en juin.

Le 19 octobre, Unit 42 a constaté que les groupes de rançongiciels Qilin et Inc s'en servent désormais pour entrer dans des réseaux d'entreprises en contournant la double authentification. Ils descendent ensuite jusqu'aux serveurs de virtualisation puis jusqu'aux sauvegardes, la dernière ligne de défense quand tout le reste a cédé, en s'aidant au passage d'une faille de Veeam publiée en 2023. Les victimes se trouvent dans la santé, l'énergie, la grande distribution, les administrations et les transports, entre autres.

Palo Alto Networks parle de tentatives limitées, sur des équipements ni corrigés ni protégés par le contournement documenté. Cinq mois après le correctif, des VPN d'entreprise restaient donc ouverts à qui connaissait la faille. Elle n'a jamais reçu de nom, et deux jours après l'alerte d'Unit 42, tout le secteur avait les yeux tournés vers PHP.

Pourquoi une faille exploitée reste-t-elle ouverte pendant des mois ?

Le cas n'a rien d'isolé. J'ai raconté dimanche dernier comment environ 700 supermarchés ont vu leurs chambres froides déréglées à distance par des régulateurs Danfoss que leur fabricant ne maintenait plus. Un chiffre est venu s'ajouter depuis : entre le 7 septembre et le 6 octobre, un mois après la publication de nouvelles failles de ces régulateurs, l'assureur Coalition en comptait encore 820 exposés sur des réseaux français, plus de la moitié de ceux qu'il observait dans le monde.

Le décalage de décision, cet écart entre le moment où un risque est connu et celui où quelqu'un le traite, n'a ici aucune explication technique. Un micrologiciel se met à jour en une intervention, un VPN en une fenêtre de maintenance. Les blocages sont ailleurs, et je les retrouve dans presque toutes les organisations. Le premier tient à l'inventaire, parce qu'on ne met pas à jour un équipement dont on ignore l'existence, et en septembre un assureur connaissait mieux les régulateurs frigorifiques français exposés que leurs propriétaires. Le deuxième tient à la propriété. Redémarrer le VPN coupe le télétravail de toute l'entreprise, et la fenêtre de maintenance se négocie avec des métiers qui n'ont aucune raison de la céder pour une faille dont personne ne parle, quand le régulateur frigorifique appartient au service technique et à un prestataire dont le contrat prévoit rarement la moindre veille de sécurité. Le troisième tient à la mesure : les équipes chargées des correctifs sont jugées sur le nombre de failles critiques qu'elles ferment, ce qui récompense ce qui porte l'étiquette, quel que soit le danger réel.

La semaine PHP a fourni la contre-épreuve. Ces trois blocages ont cédé en quelques jours, chez des organisations qui les opposaient d'habitude à chaque mise à jour, dès que le bruit a fabriqué de la volonté. Aucun ne se lève pourtant dans l'équipe technique. Recenser les équipements du service technique, imposer une fenêtre de maintenance aux métiers et changer la façon de mesurer le travail sont trois décisions de direction, et tant qu'elles ne sont pas prises, l'actualité trie à leur place.

Quand l'IA trouve 14 000 failles en deux mois, qui décide de ce qu'on corrige ?

Ce tri par l'actualité fonctionnait à peu près tant que les failles arrivaient au compte-gouttes, et ce temps est fini. En août, Palo Alto Networks a présenté un système qui confie la recherche de failles à plusieurs modèles d'IA. En deux mois, il en a confirmé 14 090 dans près de 4 000 logiciels open source, presque toutes inconnues jusque-là et environ 40 % de gravité élevée ou critique. Seules 85 avaient déjà été signalées par d'autres, d'où l'éditeur conclut que d'autres mènent la même chasse, attaquants compris. PHP2Shell elle-même a été découverte avec l'aide de modèles d'IA, dont Gemini, celui de Google.

Les modèles écrivent une part croissante du code des applications web, en trouvent les failles par milliers, et les attaquants qui s'en servent passent d'une faille web à l'annuaire qui gère tous les comptes d'un réseau en moins de deux heures. En face, Palo Alto Networks évalue à 55 jours le délai moyen de déploiement d'un correctif. Le chiffre vient d'un éditeur qui vend la parade, et l'ordre de grandeur suffit pourtant face à un adversaire qui compte en heures. Quand quatre découvertes sur dix sortent avec l'étiquette élevée ou critique, l'étiquette ne distingue plus rien, et l'actualité, qui ne retient qu'une poignée de failles par semaine, choisira de plus en plus arbitrairement celles qu'on traite d'abord.

Faire du bruit est devenu une responsabilité de direction

La leçon de cette quinzaine tient en une phrase que je répète aux RSSI que j'accompagne : il faut faire du bruit, parce que le bruit fabrique la volonté qui manque. L'actualité en fabrique sur les failles qui ont un nom et un communiqué. Le RSSI doit en fabriquer sur les autres, la faille de pare-feu exploitée depuis cinq mois, l'équipement oublié sur Internet, le matériel que plus personne ne maintient, et ce bruit-là se construit en jours d'arrêt, en chambres froides perdues et en portes ouvertes à un rançongiciel.

Le bruit reste pourtant un levier, et une direction qui n'agit que lorsque la presse s'en mêle n'a pas de volonté propre. C'est là que se loge la crise de leadership : un VPN sans correctif depuis mai est un risque accepté que personne n'a signé. J'écrivais dimanche dernier qu'on accepte le risque cyber comme on choisit la plante de la réception. La semaine PHP en montre l'autre face. Quand la direction ne décide pas, quelqu'un décide à sa place, et celle qui laisse la note de gravité et la presse spécialisée trier ses correctifs a délégué son appétence au risque à une formule de calcul et à une salle de rédaction. La directive NIS2 confie pourtant cette décision aux organes de direction, une responsabilité qui n'a jamais attendu la transposition pour exister.

L'IA a désormais la parole à chaque étape technique, de l'écriture du code à la conduite de l'intrusion. La seule étape qui reste humaine est la décision de ce qu'on corrige en premier, et c'est aussi la plus lente.

Ce qui protégerait réellement

Rendre cette décision plus rapide que l'actualité ne demande ni outil miracle ni loi nouvelle. La première règle consiste à fixer l'urgence d'une correction sur deux questions avant de regarder la note : la faille est-elle exploitée, et l'équipement est-il visible depuis Internet ? Quand la réponse est oui aux deux, la correction ou le contournement se fait sous 72 heures, et tout retard exige une dérogation signée par un membre du comité de direction, datée et assortie d'une échéance. Avec cette règle, le VPN n'attend pas cinq mois, et une faille étiquetée « élevée » comme Node2Shell remonte en tête de file dès la première attaque constatée.

Encore faut-il savoir ce qui est exposé. L'inventaire doit couvrir les équipements techniques, régulateurs frigorifiques et gestion technique du bâtiment compris, se vérifier chaque trimestre depuis l'extérieur et porter un propriétaire nommé sur chaque ligne, parce qu'une organisation qui découvre son exposition dans le rapport d'un assureur a déjà perdu la course.

Ce que le fabricant ne maintient plus mérite son propre registre. Anciennes versions de PHP et de Node.js, régulateurs abandonnés, listes d'autorités de confiance figées dans les équipements : chaque ligne doit passer une fois par an en comité de direction et recevoir une date de remplacement ou une acceptation de risque signée. Les applications générées par IA y entrent aussi, et aucune ne devrait partir en production sans la liste de ses composants et de leurs versions, faute de quoi celle qui tourne sur Node.js sans le savoir ne recevra jamais le correctif de Node2Shell.

Reste l'indicateur présenté à la direction. Le délai entre la première exploitation connue d'une faille et sa correction sur les équipements exposés doit remplacer le nombre de failles critiques fermées dans le mois, qui ne mesure que l'activité de l'équipe.

Le 13 mai, la faille du VPN de Palo Alto Networks était officiellement signalée comme exploitée. Le 17 octobre, les clés d'eMudhra tombaient en moins d'une seconde. Le 19, Qilin et Inc apparaissaient dans la note d'Unit 42. Le 21, tout le secteur corrigeait PHP. La prochaine faille silencieuse touchera peut-être un poste électrique ou un réseau d'eau, et le bruit, ce jour-là, arrivera lui aussi après.

À lire également

• On accepte le risque cyber comme on choisit la plante de la réception
• Le Parlement n'a jamais été votre RSSI
• La seule sauvegarde qui compte est celle qu'on a déjà restaurée
• ReCyF, backdoors et clés USB : la France en cybersécurité, entre lucidité et anachronisme
• Free : l'amende se discute au Conseil d'État, le hameçonnage continue
• DGFiP : ils le savaient depuis fin juin, vous l'apprenez le 13 août
• Les gestes pratiques pour se protéger sur etrecyber.fr

Sources

• PHP, Security advisory: Critical remote code execution vulnerabilities, update now, 21 octobre 2026, et notes de version de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sur le dépôt php-src.
• Palo Alto Networks Unit 42, Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619, mis à jour le 23 octobre 2026, pour l'intrusion agentique et le décompte de 22,6 millions d'instances.
• Red Hat, CVE-2026-109618, fiche de sécurité, octobre 2026.
• Help Net Security, PHP2Shell: Critical PHP vulnerabilities patched, update now!, 21 octobre 2026, pour la tentative captée par Amazon Threat Intelligence le 17 octobre ; watchTowr, PHP2Shell FAQ, octobre 2026.
• Google Cloud, Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619, octobre 2026.
• Node.js, publication de sécurité du 21 octobre 2026 (versions 22.23.4, 24.22.1 et 26.12.1) ; Debian Security Tracker et OSV, CVE-2026-111497 ; Aikido Security, Node2Shell: Node.js Brotli vulnerability allows remote code execution, et Qualys, Node.js Patches Brotli Remote Code Execution Flaw, octobre 2026 ; Rescana, octobre 2026, pour les chemins d'exposition démontrés par Imperva ; Cybernews, octobre 2026, pour l'absence d'exploitation constatée.
• Vercel, Bolt.new et Lovable, piles par défaut recensées par Fively, Best Tech Stack for Vibe Coding, et Appwrite, Best frontend frameworks for vibe coding, 2026.
• The Register, Indian certification authority eMudhra's private keys compromised, 20 octobre 2026, citant l'annonce de Dennis Jackson (Mozilla), et Certification authority eMudhra defends its laughably weak private keys, 22 octobre 2026 ; Help Net Security, eMudhra security blunder left trusted CA signing keys exposed to anyone, octobre 2026, pour le rapport d'incident de Mozilla ; The Record, Indian tech company eMudhra announces withdrawal from certificate business after security incident, et CyberScoop, octobre 2026, pour la déclaration de V. Srinivasan, la réaction du ministère indien et le constat du CERT-In ; Rescana et Endor Labs, octobre 2026, pour les mises à jour des listes de confiance hors navigateurs.
• Palo Alto Networks Unit 42, Active Exploitation of May 2026 PAN-OS CVE-2026-0257, mise à jour du 19 octobre 2026 ; CISA, Known Exploited Vulnerabilities Catalog, inscription du 13 mai 2026.
• Palo Alto Networks Unit 42, The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software, 4 août 2026.
• The Register, Researchers warned attackers could 'defrost the food' months before French supermarkets got hit, 15 octobre 2026, pour les relevés de Coalition sur les interfaces Danfoss exposées.
• Directive (UE) 2022/2555 du 14 décembre 2022, dite NIS2, article 20.