À chaque nouvelle faille découverte, un réflexe bien rodé se met en place : les agences de cybersécurité publient une alerte, les éditeurs diffusent un correctif, et les experts appellent à réagir vite. Mais cette mécanique, pensée pour protéger, produit aujourd’hui l’effet inverse : elle alimente les attaques en temps réel car dans les faits, les pirates ne cherchent plus les vulnérabilités, ils les attendent.
Une fois la faille rendue publique, le compte à rebours commence. Scanners automatisés, bots, rétro-ingénierie des correctifs… Les outils offensifs intègrent la faille en quelques heures avant même que les entreprises aient pu réagir.
L’ANSSI elle-même le reconnaît dans son rapport 2024 :
« Quelques jours, parfois même quelques heures suffisent aux attaquants après la publication d’une faille. »
Un constat glaçant qui questionne le modèle actuel : faut-il continuer à tout publier, aussi vite et aussi ouvertement ?
De la publication à l’exploitation : l’ère du piratage en temps réel
Le temps où les entreprises pouvaient « prendre le temps » d’appliquer les correctifs de sécurité est révolu. Aujourd’hui, il ne s’agit plus de jours ni même d’heures, mais de minutes. Le cas Log4Shell (CVE-2021-44228) l’a prouvé de façon brutale : neuf minutes seulement après la divulgation publique de la faille, les premières tentatives d’exploitation ont été détectées sur Internet. Pas le temps de lire l’alerte et encore moins de patcher, les assaillants étaient déjà à l’œuvre.
Ce n’est plus un cas isolé. En 2025, selon le rapport VulnCheck, 28,3 % des failles connues (CVE) sont activement exploitées dans les 24 heures suivant leur publication. Autrement dit, près d’un tiers des vulnérabilités rendues publiques deviennent, immédiatement ou presque, des armes à portée de script kiddies et de groupes bien organisés.
Cette dynamique crée un nouvel équilibre de la terreur : le simple fait de signaler une faille devient une alerte rouge pour les défenseurs mais aussi pour les attaquants. Ce phénomène démontre à quel point la frontière entre transparence et imprudence est devenue fine dans la cybersécurité.
Fuite de vulnérabilités : le rôle caché des bases publiques (CVE, NVD)
Lorsqu’une faille est découverte, elle entre généralement dans un cycle appelé divulgation coordonnée. Mais ce processus, censé permettre aux éditeurs de corriger à temps est de plus en plus court-circuité. Aujourd’hui, l’enregistrement d’une CVE (Common Vulnerabilities and Exposures) dans une base publique peut suffire à déclencher un compte à rebours côté attaquants.
Une fois qu’une faille reçoit son identifiant (ex. CVE-2025-XXXX), elle est référencée dans des bases ouvertes comme la NVD (National Vulnerability Database) ou CVE Details. Ces bases sont précieuses pour les professionnels de la cybersécurité. Elles listent la faille, les logiciels concernés, la gravité, parfois même le code d’exploitation. Et ce sont ces mêmes bases que les hackers surveillent en temps réel (souvent via des flux RSS ou API automatisées) pour identifier les nouvelles opportunités.
L’étape suivante est l’analyse, des scripts sont rapidement générés à partir de la description technique avant qu’un patch soit publié. Dans certains cas, les chercheurs en sécurité eux-mêmes publient une preuve de concept (PoC) sur GitHub ou Pastebin qu’il suffit ensuite de copier-coller pour attaquer des systèmes vulnérables. Ce n’est plus du hacking sophistiqué, c’est du piratage assisté.
En rendant publiques ces informations sans contrôle d’accès, la communauté de la cybersécurité outille involontairement les groupes malveillants.
Le rôle involontaire des institutions dans cette mécanique infernale
À l’origine, la transparence des institutions comme la CNIL, l’ANSSI ou les différents CERT (Computer Emergency Response Teams) répond à un objectif d’alerter les entreprises, protéger les usagers et améliorer la résilience du numérique. Mais cette bonne intention se heurte à une réalité beaucoup plus crue : les hackers aussi lisent ces rapports. Et ils sont souvent les premiers à passer à l’action.
Dans de nombreux cas, les alertes officielles documentent des failles encore non corrigées. Elles précisent les logiciels concernés, les vecteurs d’attaque, les systèmes vulnérables, voire les conditions exactes d’exploitation. Ces publications techniques deviennent, malgré elles, des modes d’emploi prêts à l’usage, distribués gratuitement et légalement à toute personne capable de lire un PDF.
Le mythe du 0-day s’efface peu à peu. Aujourd’hui, les cybercriminels n’ont plus besoin de découvrir une faille inédite : il leur suffit d’attendre que les institutions les publient. Ce décalage entre alerte institutionnelle et capacité à patcher crée un moment de grande vulnérabilité exploité systématiquement.
Les institutions ne sont pas les coupables. Mais leur logique de publication alimente une mécanique infernale : plus les failles sont visibles, plus elles sont utilisées. Et tant que la chaîne de correction reste plus lente que celle de l’attaque, le système tourne à l’envers.
Faut-il restreindre la divulgation des failles de sécurité ?
Tant que les failles de sécurité seront publiées en libre accès immédiatement après leur découverte, les attaquants n’auront même plus besoin de chercher des 0-day : les institutions les leur mâchent. Ce n’est pas un problème technique, c’est une erreur de stratégie.
Aujourd’hui, la cybersécurité est encore traitée comme un domaine d’expertise académique : publications ouvertes, langage normatif, délais théoriques. Or dans les faits, cette approche alimente une mécanique perverse : à chaque CVE publiée, ce sont des milliers de serveurs, d’hôpitaux ou de PME qui deviennent vulnérables avant même que le patch ne soit prêt ou qu’il ait été appliqué.
Il faut changer de paradigme, créer un guichet unique, sécurisé, permettant de signaler une faille à une cellule centralisée, qui en informera d’abord les professionnels concernés (éditeurs, responsables de sécurité, hébergeurs critiques) avant toute publication. C’est le principe d’une divulgation différée, ciblée, et maîtrisée, pas une censure, mais une séquence logique : colmater avant de publier.
Cette temporalité doit être redéfinie à l’échelle nationale. Il ne s’agit plus de publier pour publier, mais de publier quand cela ne nuit plus à la défense des systèmes. Tant que les alertes techniques seront lues plus vite par les hackers que par les RSSI, nous jouons contre notre propre camp.
Sources et ressources
Cet article vous a-t-il été utile ?
À propos de l'auteur
Adrien Piron
