Le chiffre est tombé comme un coup de semonce. Selon les projections du FIRST (Forum of Incident Response and Security Teams), l'année 2026 devrait voir la publication d'environ 66 000 CVE — des identifiants uniques attribués à des vulnérabilités logicielles confirmées. En 2020, ce chiffre était de 18 000. En 2024, il atteignait déjà 40 000. La courbe n'est plus linéaire. Elle est exponentielle. Et la cause principale de cette accélération n'est pas une dégradation de la qualité du code — c'est l'arrivée massive de l'IA dans la chasse aux vulnérabilités.
Pour les développeurs open source français, cette réalité change profondément la donne. Chaque bibliothèque que vous maintenez, chaque dépendance que vous intégrez, chaque projet auquel vous contribuez est désormais soumis à un niveau de scrutin automatisé sans précédent. Les LLM spécialisés en sécurité ne dorment pas, ne se fatiguent pas, et ne s'arrêtent pas au premier bug trouvé. Ils scannent méthodiquement des millions de lignes de code, identifient des classes entières de failles, et génèrent des rapports détaillés avec preuves de concept. Le tsunami de CVE est là. Il reste à savoir comment s'y préparer.
Cet article décrypte les données du FIRST, analyse le rôle de l'IA dans cette explosion — avec des exemples concrets de CVE récentes — et propose des actions immédiates pour les développeurs français confrontés à cette nouvelle réalité. Sources principales : FIRST et Help Net Security.
L'explosion des CVE en 2026 : les chiffres clés
Les chiffres parlent d'eux-mêmes. En 2020, le programme CVE du MITRE enregistrait environ 18 000 vulnérabilités. Ce chiffre était déjà considéré comme élevé par la communauté sécurité. En 2021, il passait à 20 000. En 2022, à 25 000. Puis l'accélération a commencé : 29 000 en 2023, 40 000 en 2024 — un bond de 38% en un an. En 2025, les estimations pointaient déjà vers 52 000. Et maintenant, le FIRST projette 66 000 CVE pour 2026.
Pour mettre ces chiffres en perspective : 66 000 CVE en une année, c'est 180 nouvelles vulnérabilités publiées chaque jour. Chaque. Jour. Aucune équipe de sécurité au monde, aussi performante soit-elle, ne peut traiter manuellement ce volume. Même les grandes entreprises du CAC 40 avec des équipes dédiées peinent à suivre le rythme de 40 000 CVE par an. À 66 000, le modèle de triage manuel est définitivement mort.
La bonne nouvelle — si l'on peut appeler ça ainsi — c'est que seule une fraction de ces CVE nécessite une réaction immédiate. Sur les 66 000 vulnérabilités projetées, environ 5 à 10% seront classées comme critiques ou de sévérité haute. Parmi celles-ci, une portion encore plus réduite affectera réellement vos dépendances directes et sera exploitable à distance. Le défi n'est donc pas de tout corriger — c'est de trier efficacement pour savoir où concentrer ses efforts.
💡 Notre avis d'expert
"Les mainteneurs open source bénévoles font face à un tsunami qu'ils n'ont pas les moyens d'absorber. Un mainteneur solo qui reçoit 15 rapports de vulnérabilités en une semaine — générés automatiquement par des outils IA — ne peut pas tous les traiter avec le soin nécessaire. C'est un problème systémique, pas individuel."
Comment l'IA découvre les failles plus vite que les humains
L'accélération du nombre de CVE n'est pas un hasard. Elle coïncide précisément avec l'adoption massive des LLM (Large Language Models) pour l'audit de sécurité automatisé. Le principe est simple : un modèle de langage spécialisé reçoit le code source d'un projet, l'analyse ligne par ligne, et identifie des patterns connus de vulnérabilités — injections SQL, cross-site scripting (XSS), débordements de buffer, erreurs de validation d'entrée, race conditions, fuites de mémoire, escalades de privilèges.
Ce qui rend l'IA redoutablement efficace dans ce domaine, c'est sa capacité à suivre les flux de données à travers un codebase entier. Un chercheur humain qui audite un projet de 500 000 lignes de code doit garder en tête les dépendances entre fichiers, les appels de fonctions imbriqués, les transformations de données successives. C'est un exercice cognitif épuisant qui limite la profondeur de l'analyse. Un LLM n'a pas cette contrainte. Il peut modéliser simultanément des centaines de chemins d'exécution et identifier des vulnérabilités qui impliquent des interactions complexes entre composants distants du code.
Les exemples concrets de juin 2026 illustrent cette réalité. Prenons trois CVE récentes qui touchent des projets largement utilisés :
- CVE-2026-20266 — Splunk AI Toolkit : une vulnérabilité permettant à un administrateur authentifié d'exécuter des commandes OS arbitraires sur le serveur. Le vecteur d'attaque passe par une injection dans les paramètres de configuration des modèles IA intégrés. Ce type de faille — où un champ de configuration est interprété comme une commande système — est exactement le genre de pattern qu'un LLM détecte en quelques minutes en scannant le code de traitement des entrées.
- CVE-2026-41696 — Spring Data MongoDB : une erreur de validation dans les expressions régulières utilisées pour filtrer les requêtes MongoDB. Un attaquant peut injecter une regex malveillante qui provoque un ReDoS (Regular Expression Denial of Service), rendant le service indisponible. Les vulnérabilités ReDoS sont notoirement difficiles à détecter manuellement — elles nécessitent de comprendre la complexité computationnelle d'une regex spécifique. Les outils IA, eux, les identifient systématiquement.
- CVE-2026-41717 — Spring Expression Language (SpEL) injection : une faille d'injection SpEL qui permet l'exécution de code arbitraire dans les applications Spring. Les injections SpEL sont particulièrement dangereuses parce qu'elles donnent un accès complet au runtime Java. Ce type de vulnérabilité apparaît quand des entrées utilisateur sont passées directement à un évaluateur SpEL sans sanitisation — un pattern que l'IA repère en analysant le graphe de flux de données.
Le point commun de ces trois CVE : elles relèvent de classes de vulnérabilités bien connues (injection de commandes, ReDoS, injection d'expression) que les outils IA sont particulièrement doués pour détecter. Ce qui prenait auparavant des dizaines de chercheurs qualifiés travaillant pendant des mois peut désormais être accompli en quelques heures par un LLM bien instrumenté scannant systématiquement un codebase.
💡 Notre avis d'expert
"Le projet Glasswing d'Anthropic a démontré qu'un seul modèle IA peut découvrir en quelques semaines ce que des centaines de chercheurs mettraient des années à trouver. Claude Mythos, le modèle utilisé dans Glasswing, a identifié des milliers de vulnérabilités de sévérité haute et critique à travers l'écosystème open source. Ce n'est pas de la science-fiction — c'est la réalité de juin 2026."
L'impact sur les développeurs open source français
La France possède l'un des écosystèmes open source les plus dynamiques d'Europe. Des projets comme Symfony, Haskell Stack, de nombreuses contributions à Linux, et un tissu dense de PME et de freelances qui utilisent massivement des bibliothèques open source dans leurs projets. Cette réalité place les développeurs français en première ligne face à l'explosion des CVE.
Le premier impact est direct : la charge de maintenance sécurité explose. Un développeur freelance qui maintient un projet open source populaire — disons une bibliothèque Python avec 50 000 téléchargements mensuels — va recevoir de plus en plus de rapports de vulnérabilités générés automatiquement par des outils IA. Certains seront légitimes. D'autres seront des faux positifs. Tous nécessiteront du temps pour être évalués, triés et traités. C'est du temps non rémunéré pour un mainteneur bénévole.
Le deuxième impact concerne les pratiques de développement. Avec 180 CVE publiées par jour, les équipes de développement ne peuvent plus se permettre de vérifier manuellement les vulnérabilités affectant leurs dépendances. L'intégration d'outils d'analyse automatisée dans les pipelines CI/CD n'est plus un luxe — c'est une nécessité opérationnelle. Des outils comme Trivy, Grype, ou Snyk doivent faire partie de chaque workflow de déploiement.
Le troisième impact est économique. Les entreprises françaises soumises aux réglementations NIS2 et DORA doivent démontrer qu'elles gèrent activement les risques liés à leurs dépendances logicielles. Avec 66 000 CVE par an, les audits de sécurité deviennent plus fréquents et plus coûteux. Pour les experts en sécurité, c'est une opportunité commerciale. Pour les entreprises qui ne se préparent pas, c'est un risque réglementaire croissant.
💡 Notre avis d'expert
"Le modèle actuel du bénévolat open source est en train de craquer sous la pression. Des mainteneurs non rémunérés, qui travaillent sur leur temps libre, se retrouvent submergés par des rapports de vulnérabilités générés par des machines. Sans financement structurel — via des programmes comme Tidelift, GitHub Sponsors, ou le Sovereign Tech Fund européen — des projets critiques vont devenir des bombes à retardement."
Ce que ça signifie pour vous
Face à cette réalité, l'attentisme n'est pas une option. Voici les quatre actions concrètes que chaque développeur et chaque équipe technique en France devrait mettre en place immédiatement.
1. Adoptez un SBOM (Software Bill of Materials)
Un SBOM est l'inventaire exhaustif de toutes les dépendances — directes et transitives — de votre projet. Sans SBOM, vous ne savez même pas si une CVE publiée vous concerne. Avec un SBOM, vous pouvez croiser automatiquement les nouvelles CVE avec votre inventaire de dépendances et identifier en quelques secondes si vous êtes affecté. Des outils comme syft (Anchore), cyclonedx-bom ou spdx-sbom-generator génèrent un SBOM en une commande depuis votre projet. Intégrez-le dans votre CI/CD dès aujourd'hui.
2. Intégrez un scanner de vulnérabilités dans votre CI/CD
Chaque git push devrait déclencher un scan automatisé des dépendances. Trivy (open source, AquaSecurity) est le standard de facto pour les projets containers et les dépendances applicatives. Grype (Anchore) est une alternative légère et rapide. Snyk offre une version gratuite pour les projets open source. L'objectif n'est pas de bloquer chaque build qui contient une CVE — c'est de savoir, en temps réel, quelles vulnérabilités affectent votre code en production.
3. Mettez en place une stratégie de triage
180 CVE par jour, c'est ingérable si vous essayez de tout traiter. La clé est le triage systématique. Posez-vous trois questions pour chaque CVE qui apparaît dans votre scanner :
- Est-ce que cette CVE affecte une dépendance que j'utilise directement ? Les vulnérabilités dans des dépendances transitives profondes sont souvent inexploitables dans votre contexte.
- Est-ce que la vulnérabilité est exploitable à distance ? Une faille qui nécessite un accès physique au serveur est bien moins urgente qu'une RCE (Remote Code Execution) accessible via le réseau.
- Un patch est-il disponible ? Si oui, la mise à jour est la réponse immédiate. Si non, évaluez les mesures de mitigation temporaires (WAF rules, configuration hardening).
4. Contribuez en amont
Si votre entreprise dépend d'un projet open source critique, ne vous contentez pas de consommer — contribuez. Cela peut prendre la forme de correctifs de sécurité, de revues de code, de financement via GitHub Sponsors ou Tidelift, ou simplement de rapports de bugs de qualité. Un écosystème open source plus sain produit des logiciels plus sûrs pour tout le monde — y compris pour vous.
Besoin d'un audit sécurité open source ?
Nos experts utilisent les mêmes outils IA que les attaquants — mais pour protéger votre code. Audit complet de vos dépendances, SBOM, stratégie de triage.
Demander un audit — devis gratuitPrédictions : ce qui nous attend
L'explosion des CVE n'est pas un phénomène transitoire. C'est un changement structurel de l'écosystème logiciel, et il va s'intensifier. Voici ce que nous anticipons pour les deux prochaines années.
L'IA deviendra le principal vecteur de découverte de vulnérabilités. En 2026, les outils IA sont déjà responsables d'une part significative des nouvelles CVE. D'ici 2028, cette proportion devrait dépasser 70%. Les modèles spécialisés vont devenir plus précis, plus rapides et plus accessibles. Des initiatives comme le projet Glasswing d'Anthropic vont se multiplier chez tous les grands fournisseurs d'IA — Google, Microsoft, Meta vont tous lancer des programmes similaires pour auditer l'écosystème open source.
Les CVE à zéro-day découvertes par l'IA vont poser un problème éthique. Quand un modèle IA découvre une vulnérabilité critique dans un projet largement utilisé, le processus de divulgation responsable prend du temps — typiquement 90 jours. Mais si plusieurs modèles IA trouvent la même faille indépendamment, le risque qu'un acteur malveillant la découvre aussi (ou utilise un modèle IA pour la trouver) augmente considérablement. La fenêtre de divulgation responsable va devoir se réduire.
Le financement de la sécurité open source va devenir un enjeu géopolitique. L'Union européenne a déjà lancé des initiatives comme le Sovereign Tech Fund pour soutenir les projets open source critiques. Face à 66 000+ CVE par an, la pression politique pour financer structurellement la maintenance sécurité des projets open source va s'intensifier. Les entreprises qui utilisent massivement l'open source sans contribuer — ce qu'on appelle les "free riders" — seront de plus en plus pointées du doigt.
Les SBOM deviendront obligatoires. La directive NIS2 et le Cyber Resilience Act européen vont rendre les SBOM obligatoires pour un nombre croissant de produits logiciels. Les entreprises françaises qui n'ont pas encore adopté cette pratique feraient bien de commencer maintenant — attendre la contrainte réglementaire, c'est prendre du retard sur la concurrence.
💡 Notre avis d'expert
"D'ici 2028, 90% des vulnérabilités critiques seront découvertes par l'IA avant qu'un humain ne les trouve. Ce n'est pas une question de capacité — c'est une question de mathématiques : un LLM peut scanner en une journée ce qu'une équipe de 20 chercheurs met un an à auditer. Les développeurs qui ne s'adaptent pas à cette réalité vont se retrouver submergés."
FAQ — Questions fréquentes
Pourquoi FIRST prévoit-il 66 000 CVE en 2026 ?
FIRST base ses projections sur la tendance exponentielle de découverte de vulnérabilités observée depuis 2020. Le nombre de CVE publiées a plus que triplé entre 2020 (18 000) et 2026 (66 000 projetées). Cette accélération est principalement due à l'adoption massive d'outils d'analyse automatisée par IA, qui détectent des classes entières de failles — injections, débordements, erreurs de validation — en quelques heures au lieu de mois. L'élargissement continu de la base de code open source (plus de projets, plus de dépendances) amplifie également le phénomène.
Comment l'IA découvre-t-elle des vulnérabilités dans le code open source ?
Les LLM spécialisés en sécurité analysent le code source à la recherche de patterns connus de vulnérabilités : injections SQL, XSS, débordements de buffer, erreurs de validation d'entrée, race conditions. Ils suivent les flux de données à travers le codebase entier pour identifier des chemins d'exécution vulnérables qui impliqueraient des interactions complexes entre composants distants. Un LLM bien instrumenté peut scanner un projet entier en quelques heures et générer des preuves de concept d'exploitation pour chaque faille détectée.
Que signifie le projet Glasswing d'Anthropic pour la sécurité open source ?
Le projet Glasswing utilise le modèle Claude Mythos d'Anthropic pour découvrir automatiquement des vulnérabilités dans les projets open source. Les résultats ont été spectaculaires : des milliers de failles de sévérité haute et critique identifiées en quelques semaines. Pour l'écosystème, cela signifie que les vulnérabilités cachées seront trouvées — c'est une question de temps, pas de possibilité. Mais cela signifie aussi que les mainteneurs bénévoles vont recevoir un afflux massif de rapports qu'ils devront traiter, sans forcément avoir les moyens humains et financiers de le faire rapidement.
Que doivent faire les développeurs français face à l'explosion des CVE ?
Quatre actions prioritaires. Premièrement, adoptez un SBOM pour chaque projet — savoir exactement quelles dépendances vous utilisez et à quelles versions. Deuxièmement, intégrez un scanner de vulnérabilités automatisé dans votre CI/CD (Trivy, Grype, Snyk). Troisièmement, mettez en place une stratégie de triage : concentrez-vous sur les CVE qui affectent vos dépendances directes et qui sont exploitables à distance. Quatrièmement, contribuez en amont : si vous utilisez un projet open source critique, aidez-le financièrement ou en contribuant des correctifs de sécurité.