Ressources · 23
Prioriser les vulnérabilités et vérifier les correctifs
Relier exploitation connue, actifs exposés, effet métier et preuve de remédiation.
· 10 min
Ce que ce guide permet
- Relier les alertes aux actifs
- Classer l’urgence réelle
- Déployer sans perdre le service
- Vérifier et clôturer
Contrôle express
- Le produit et sa version sont-ils réellement présents ?
- L’actif est-il accessible et critique ?
- Une exploitation active est-elle documentée ?
- Quelle mesure protège avant le correctif ?
- Le contrôle confirme-t-il la disparition du problème sur l’actif ?
Méthode pas à pas
- 01
Consolider l’inventaire
Associer services, produits, versions, environnement, exposition et responsable. Une alerte de composant ne prouve pas à elle seule que l’instance vulnérable est déployée.
Livrable : liste datée des actifs concernés et incertitudes.
- 02
Qualifier la vulnérabilité
Rapprocher l’avis du fournisseur, l’identifiant CVE, les conditions d’exploitation et, le cas échéant, le catalogue CISA des vulnérabilités exploitées. Noter la date de vérification.
Livrable : fiche de qualification avec liens primaires.
- 03
Décider de la priorité
Combiner exploitation connue, accessibilité de l’actif, privilèges requis, données traitées, effet sur le service et possibilité de remédiation. Fixer un propriétaire et une échéance adaptés au contexte.
Livrable : décision de priorité motivée.
- 04
Préparer la modification
Identifier dépendances, fenêtre de changement, sauvegarde et retour arrière. Si la mise à jour ne peut pas être appliquée immédiatement, documenter la mesure temporaire et sa durée.
Livrable : plan de déploiement et exception limitée.
- 05
Déployer et tester
Installer le correctif ou la mitigation suivant la procédure du fournisseur. Tester la version obtenue, le parcours métier et les intégrations qui pourraient régresser.
Livrable : trace de déploiement et résultat fonctionnel.
- 06
Confirmer la fermeture
Contrôler l’actif réel avec une méthode adaptée, traiter les instances oubliées et réexaminer les exceptions. Ne pas fermer un ticket sur la seule intention de mise à jour.
Livrable : preuve de validation et registre actualisé.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Couverture | Actifs critiques avec version et responsable connus | Compléter l’inventaire |
| Délai | Temps entre qualification et correction validée | Lever les blocages récurrents |
| Validation | Correctifs retestés sur l’actif réel | Rouvrir les fermetures sans preuve |
| Exceptions | Dérogations avec mesure, propriétaire et fin | Supprimer les exceptions périmées |
Erreurs fréquentes
- Classer uniquement selon un score générique sans vérifier l’actif
- Assimiler présence dans KEV à présence dans son propre parc
- Déployer sans tester le service rendu
- Laisser une mesure compensatoire sans date de révision
Questions fréquentes
Une CVE élevée doit-elle toujours passer en premier ?
Le score renseigne une gravité technique, mais l’exploitation connue, l’exposition et l’effet sur vos services orientent la décision locale.
Que faire si aucun correctif n’est disponible ?
Suivre les mesures du fournisseur, réduire l’exposition lorsque possible et consigner un responsable, une échéance de réexamen et le risque résiduel.
Quand clôturer ?
Après validation de la version ou mitigation sur les instances concernées et test du fonctionnement critique.
Références : données, usages et limites
Documentation consultée le .
| Source et objet | Donnée ou repère vérifié | Comment l’utiliser | Limite à conserver |
|---|---|---|---|
| FIRST · CVSS Décrire la gravité technique d’une vulnérabilité avec une méthode et un vecteur explicites. |
CVSS 4.0 produit des scores de 0,0 à 10,0. Les groupes Base, Threat, Environmental et Supplemental n’ont pas tous la même fonction. | Conservez la version, le vecteur et la date du score. Rapprochez le résultat de la version installée, des chemins d’accès et des conséquences métier avant d’ordonner les correctifs. | Un score élevé n’est pas une preuve d’exploitation ; un score faible ne signifie pas que le service ne présente aucun risque. |
| FIRST · EPSS Estimer la probabilité d’exploitation d’une CVE publiée. |
L’horizon du modèle est de 30 jours. Le score exprime une probabilité ; le percentile situe le score par rapport aux autres CVE. | Notez la date des données et distinguez probabilité et percentile. Complétez avec l’exposition de l’actif et les informations d’exploitation confirmée. | Le modèle ne prédit pas le préjudice pour votre organisation. Une probabilité basse n’annule pas une exposition critique. |
| CISA · Known Exploited Vulnerabilities Repérer les vulnérabilités recensées par CISA comme exploitées. |
Le catalogue relie notamment CVE, produit, date d’ajout et action requise. Son dépôt officiel propose aussi le schéma des données. | Vérifiez l’applicabilité à vos produits et conservez la date de consultation. Examinez la mesure demandée et le bulletin du fournisseur avant de conclure à la correction. | L’absence d’une CVE dans le catalogue n’établit pas son innocuité. Les échéances administratives du catalogue ne sont pas automatiquement une obligation pour toute organisation. |
CVSS, EPSS, KEV et VEX
Priorisation des vulnérabilités : quatre signaux à rapprocher de l’actif
Une file de vulnérabilités mélange souvent des informations qui répondent à des questions différentes. CVSS décrit la gravité technique, EPSS estime une probabilité d’exploitation observée, KEV recense une exploitation connue et VEX porte une déclaration d’applicabilité à un produit. La décision locale doit encore établir quelle version est déployée, comment elle est accessible et quelles conséquences aurait son exploitation.
Les repères ci-dessous sont documentaires. Les exemples EPSS, les situations et le produit VEX sont fictifs ; aucun score courant de CVE, inventaire réel ou résultat de scan n’est présenté. Cette fiche ne calcule ni CVSS, ni risque organisationnel, ni priorité automatique. Les propositions de preuves et de décision sont une méthode éditoriale locale.
Quatre panneaux indépendants : CVSS décrit la gravité ; EPSS estime l’exploitation observée à trente jours ; KEV renseigne l’exploitation connue ; VEX précise une applicabilité déclarée. Ils sont rapprochés du produit déployé et de son contexte, sans addition en un score unique.
Quatre questions, quatre types d’information
| Source | Question utile | Ce qu’elle ne permet pas de conclure seule |
|---|---|---|
| CVSS 4.0 | Quelle est la gravité technique selon les métriques retenues ? | Le score ne prouve pas une exploitation et ne remplace pas l’analyse des conséquences pour votre service. |
| EPSS | Quelle est la probabilité estimée d’observer une exploitation de cette CVE dans les trente prochains jours ? | La probabilité ne décrit pas la compromission de votre instance, ses protections ou son préjudice métier. |
| CISA KEV | Cette vulnérabilité figure-t-elle parmi celles recensées comme exploitées ? | L’inscription ne prouve pas que le produit existe dans votre parc ; l’absence ne prouve pas l’innocuité. |
| VEX | Que déclare un émetteur sur une vulnérabilité pour des produits identifiés à une date donnée ? | Une déclaration ne prouve pas à elle seule que la bonne version est déployée ni que l’émetteur est digne de confiance. |
CVSS 4.0 : conserver les groupes, le vecteur et l’auteur
Un nombre de 0 à 10 perd une partie de son sens si sa version, son vecteur et les groupes évalués disparaissent. FIRST distingue quatre nomenclatures de score : CVSS-B, CVSS-BT, CVSS-BE et CVSS-BTE. Les métriques Threat et Environmental non définies prennent des valeurs par défaut ; elles ne sont pas supprimées du calcul.
| Groupe | Rôle | Point de lecture |
|---|---|---|
| Base | Caractéristiques intrinsèques de la vulnérabilité. | Un CVSS-B publié par un fournisseur n’est pas votre décision de priorité. |
| Threat | Caractéristiques de menace pouvant évoluer dans le temps. | Dater l’évaluation et expliquer les informations d’exploitation utilisées. |
| Environmental | Caractéristiques propres à l’environnement du consommateur. | Expliciter les contrôles et l’importance des systèmes considérés plutôt que modifier silencieusement le score. |
| Supplemental | Contexte supplémentaire, par exemple Safety ou Recovery. | Ces métriques ne modifient pas le score CVSS final ; elles peuvent éclairer une analyse locale distincte. |
EPSS : lire la probabilité, le percentile et l’absence de donnée
FIRST décrit une probabilité de 0 à 1, actualisée quotidiennement, sur un horizon de trente jours. Le percentile est un rang relatif dans les vulnérabilités actuellement notées. Il ne faut ni additionner probabilité et percentile ni transformer leur couple en probabilité d’attaque de votre organisation.
| Exemple fictif | Valeurs fournies | Lecture correcte |
|---|---|---|
| Une probabilité | Probabilité : 0,05 · Percentile : Non renseigné | 0,05 correspond à 5 % de probabilité estimée d’exploitation observée dans l’horizon du modèle ; ce n’est pas un taux de compromission du parc. |
| Une probabilité et un rang | Probabilité : 0,02 · Percentile : 0,97 | Dans ce jeu fictif, 0,02 signifie 2 % et 0,97 situe le score au 97e percentile. Le rang ne transforme pas 2 % en 97 % de probabilité. |
| Aucune valeur reçue | Probabilité : Non renseigné · Percentile : Non renseigné | Une donnée manquante reste inconnue ; elle ne vaut ni zéro, ni une preuve d’absence d’exploitation. Noter l’échec ou la date de la dernière donnée disponible. |
Sept lectures utiles du schéma KEV
Le schéma du dépôt officiel CISA décrit le catalogue et ses entrées. La sélection suivante aide à conserver le contexte d’une consultation ; elle ne constitue pas un inventaire exhaustif de ses champs. Une entrée doit être rapprochée de l’avis fournisseur et de l’actif réel.
| Champs | Lecture | Contrôle proposé |
|---|---|---|
| catalogVersion / dateReleased | Version et date de publication du catalogue. | Garder une référence à l’édition consultée ; distinguer cette date de celle de votre analyse. |
| cveID / vendorProject / product | Identifiant et produit associés à l’entrée. | Rapprocher nom, version, distribution et éventuel composant embarqué avant de déclarer l’actif concerné. |
| dateAdded | Date d’ajout au catalogue. | Ne pas la présenter comme la date de première exploitation ou de publication de la CVE. |
| requiredAction | Action demandée pour traiter la vulnérabilité. | Lire la consigne complète et les références fournisseur, puis documenter son application locale. |
| dueDate | Date d’échéance de l’action demandée dans le catalogue. | Vérifier le contexte et la portée de la consigne CISA avant de la reprendre dans une échéance locale. |
| knownRansomwareCampaignUse | Known indique un usage confirmé dans une campagne de rançongiciel ; Unknown indique l’absence de confirmation par CISA. | Ne pas traduire Unknown par « jamais utilisé » ou par une valeur fausse certaine. |
| cwes | Codes de catégories de faiblesse associés à l’entrée. | Utiliser ces catégories pour regrouper des causes ; elles ne remplacent pas l’identifiant CVE ni la version affectée. |
Six situations fictives : quelle information manque avant de décider ?
Gravité élevée, produit non retrouvé
Un bulletin annonce une gravité élevée ; l’inventaire ne permet pas de retrouver la version dans le parc.
Confirmer présence et version auprès du propriétaire, y compris dans les dépendances embarquées.
Garder l’état « applicabilité à établir ». Une absence dans un inventaire incomplet ne justifie pas une clôture.
Exploitation connue, instance exposée
L’entrée figure dans un catalogue d’exploitation connue et le propriétaire confirme une version concernée accessible depuis Internet.
Examiner les actions fournisseur et organiser la réduction d’exposition et la remédiation adaptées au service.
Nommer le responsable, la mesure provisoire et la preuve de validation attendue ; un score de gravité seul n’ajoute pas cette traçabilité.
Probabilité basse, service essentiel
La probabilité EPSS fictive est basse, mais l’instance affectée traite un service essentiel.
Évaluer les conséquences et les chemins d’accès avant d’arbitrer une fenêtre de changement.
Ne pas utiliser le faible score comme une assurance ; les protections de cette instance ne sont pas des entrées contextuelles du modèle EPSS.
Déclaration VEX pour une autre version
Le fournisseur déclare la version 2.4.0 non affectée ; l’actif porte encore la version 2.3.0.
Rechercher une déclaration applicable à la version installée et vérifier sa provenance.
Ne pas étendre une conclusion d’une version à une autre. Le texte VEX ne déploie aucune mise à jour.
Mesure temporaire devenue permanente
Une règle temporaire réduit l’accès ; sa date de réexamen est dépassée.
Vérifier qu’elle protège toujours le chemin visé, puis décider de son maintien ou du correctif.
Conserver propriétaire, limites et nouvelle échéance. Une protection de périmètre n’est pas automatiquement une mitigation intégrée au produit au sens d’OpenVEX.
Correctif annoncé, déploiement à vérifier
Une version corrigée est disponible, mais le ticket ne contient qu’un lien de téléchargement.
Vérifier la version effectivement déployée, les instances restantes et les fonctions critiques.
Clôturer sur une preuve d’application et de contrôle, pas sur la disponibilité d’un correctif chez le fournisseur.
Huit éléments d’une décision de remédiation traçable
- Produit, version ou build, environnement et propriétaire de l’actif.
- Identifiant de vulnérabilité, avis fournisseur et conditions d’exploitation pertinentes.
- Version CVSS, vecteur, nomenclature des groupes et auteur de l’évaluation.
- Date EPSS, probabilité et percentile conservés dans des champs distincts, ou absence explicitée.
- État KEV daté, action demandée et référence de l’édition consultée.
- Déclaration VEX applicable : émetteur, produit, version, date et justification éventuelle.
- Décision locale motivée, mesure transitoire, responsable et date de réexamen.
- Preuve de déploiement ou de mitigation, résultat du contrôle et limites restantes.
Lire les statuts VEX et leurs conditions d’applicabilité →
Sources primaires et périmètre
- FIRST · CVSS 4.0 Specification · CVSS 4.0 · document 1.2 · reviewed 2026-10-22
Overview · Assessment · Nomenclature · Supplemental Metrics - FIRST · EPSS Frequently Asked Questions · Living FAQ · reviewed 2026-10-22
What is EPSS? · Reading the score · Percentile · Score changes - CISA · KEV official data schema · Official CISA mirror · reviewed 2026-10-22
Catalog properties · vulnerability properties · required fields - OpenVEX · Specification v0.2.0 · OpenVEX v0.2.0 · reviewed 2026-10-22
Statement Data Structure · Status Labels · Status Justifications · Data Inheritance
Sources vérifiées le
Signature et provenance du build
Vérifier l’origine du correctif puis son application
Une version corrigée doit être reliée au paquet reçu et à l’instance mise à jour. Vérifier sa provenance aide à établir l’origine attendue ; confirmer la remédiation exige encore de contrôler la version active et le comportement concerné.
- Conserver le digest du correctif accepté et les résultats de vérification de signature et de provenance.
- Rapprocher ce paquet de la version effectivement déployée sur chaque instance visée.
- Ne pas fermer le dossier sur l’authenticité seule : documenter contrôle de remédiation, régressions et limites restantes.
Lire la fiche de provenance avant déploiement →
Sources vérifiées le · SLSA 1.2 · Build: Verifying artifacts · SLSA 1.2 · Build: Provenance · SLSA 1.2 · Build: Track Basics · in-toto · Statement v1 · Sigstore · Verifying Signatures
Explorer le catalogue KEV de CISA
Le KEV est un catalogue CISA de vulnérabilités dont l’exploitation est connue. Cette édition consultable reprend un instantané complet et daté, pas un flux en direct. Une correspondance de nom ou de CVE constitue une piste à rapprocher du produit et de la version réellement déployés ; elle ne prouve pas qu’un système du visiteur est vulnérable ou compromis.
Les notices, noms de produits, descriptions, actions et liens conservent la langue et les valeurs de CISA. Les textes d’explication sont éditoriaux. Le catalogue peut être corrigé ou enrichi après cet instantané : consulter la source officielle avant une décision opérationnelle.
- Notices
- 1769
- Libellés fournisseur/projet distincts
- 291
- Date de publication du catalogue
Les compteurs décrivent uniquement cet instantané. Ils ne mesurent ni le nombre d’attaques, ni la prévalence des vulnérabilités, ni le risque d’une organisation. Les libellés vendorProject sont comptés tels que publiés, sans fusion d’alias et sans les assimiler à autant d’entreprises.
Unknown signifie que CISA ne confirme pas l’usage dans une campagne de rançongiciel ; cela ne signifie pas absence d’exploitation. Yes/No de forensicTriage est un indicateur distinct, décrit par le schéma avec un renvoi à BOD 26-04. Une valeur absente reste non renseignée. Ni No ni Unknown ne démontre l’absence de compromission de votre actif.
dueDate est l’échéance publiée dans la notice CISA pour l’action indiquée. Elle ne constitue pas un SLA universel, une date de publication du correctif ou une preuve que celui-ci a été installé. Le champ forensicTriage ne suffit pas, à lui seul, à déterminer vos obligations ou à définir un plan d’investigation.
Six lectures qui évitent une mauvaise priorité
| Champ publié | Lecture utile | Conclusion à éviter |
|---|---|---|
| cveID | Relier les sources qui parlent de la même vulnérabilité. | L’année de l’identifiant ne date pas l’entrée dans KEV. |
| vendorProject · product | Retrouver l’avis fournisseur et l’inventaire local. | Un nom de produit ne remplace pas les versions et configurations affectées. |
| dateAdded | Dater l’entrée de la notice dans ce catalogue. | Ne pas l’appeler date de découverte ou de première exploitation. |
| dueDate · requiredAction | Lire ensemble l’échéance et l’action publiées. | Ne pas transformer cette date en obligation universelle ni en preuve de correction. |
| knownRansomwareCampaignUse | Conserver Known, Unknown ou l’absence du champ. | Unknown ne signifie pas No et ne retire pas le constat d’exploitation connu qui motive KEV. |
| forensicTriage · cwes | Distinguer l’indicateur CISA et les classes de faiblesse publiées. | Une CWE n’est ni un produit précis, ni un score ; No n’est pas un certificat d’absence d’incident. |
Ajouts au catalogue par année
| Année d’entrée | Notices |
|---|---|
| 2021 | 311 |
| 2022 | 555 |
| 2023 | 187 |
| 2024 | 186 |
| 2025 | 245 |
| 2026 | 285 |
Résultats : 555 / 1769 · Page 6 / 23
| CVE | Fournisseur ou projet · product | Date d’entrée / Échéance de la notice | Usage dans des campagnes de rançongiciel / forensicTriage |
|---|---|---|---|
| CVE-2019-7193 CWE-20 | QNAP QTS Notice et action publiées par CISAQNAP QTS Improper Input Validation VulnerabilityQNAP QTS contains an improper input validation vulnerability allowing remote attackers to inject code on the system.
|
|
|
| CVE-2019-7194 CWE-22 | QNAP Photo Station Notice et action publiées par CISAQNAP Photo Station Path Traversal VulnerabilityQNAP devices running Photo Station contain an external control of file name or path vulnerability allowing remote attackers to access or modify system files.
|
|
|
| CVE-2019-7195 CWE-22 | QNAP Photo Station Notice et action publiées par CISAQNAP Photo Station Path Traversal VulnerabilityQNAP devices running Photo Station contain an external control of file name or path vulnerability allowing remote attackers to access or modify system files.
|
|
|
| CVE-2022-26134 CWE-917 | Atlassian Confluence Server/Data Center Notice et action publiées par CISAAtlassian Confluence Server and Data Center Remote Code Execution VulnerabilityAtlassian Confluence Server and Data Center contain a remote code execution vulnerability that allows for an unauthenticated attacker to perform remote code execution.
|
|
|
| CVE-2010-0738 CWE-264 | Red Hat JBoss Notice et action publiées par CISARed Hat JBoss Authentication Bypass VulnerabilityThe JMX-Console web application in JBossAs in Red Hat JBoss Enterprise Application Platform performs access control only for the GET and POST methods, which allows remote attackers to send requests to this application's GET handler by using a different method.
|
|
|
| CVE-2010-0840 | Oracle Java Runtime Environment (JRE) Notice et action publiées par CISAOracle JRE Unspecified VulnerabilityUnspecified vulnerability in the Java Runtime Environment (JRE) in Java SE component allows remote attackers to affect confidentiality, integrity, and availability via Unknown vectors.
|
|
|
| CVE-2010-1428 CWE-264 | Red Hat JBoss Notice et action publiées par CISARed Hat JBoss Information Disclosure VulnerabilityUnauthenticated access to the JBoss Application Server Web Console (/web-console) is blocked by default. However, it was found that this block was incomplete, and only blocked GET and POST HTTP verbs. A remote attacker could use this flaw to gain access to sensitive information.
|
|
|
| CVE-2012-1710 | Oracle Fusion Middleware Notice et action publiées par CISAOracle Fusion Middleware Unspecified VulnerabilityUnspecified vulnerability in the Oracle WebCenter Forms Recognition component in Oracle Fusion Middleware allows remote attackers to affect confidentiality, integrity, and availability via Unknown vectors related to Designer.
|
|
|
| CVE-2013-0074 | Microsoft Silverlight Notice et action publiées par CISAMicrosoft Silverlight Double Dereference VulnerabilityMicrosoft Silverlight does not properly validate pointers during HTML object rendering, which allows remote attackers to execute code via a crafted Silverlight application.
|
|
|
| CVE-2013-0422 CWE-264 | Oracle Java Runtime Environment (JRE) Notice et action publiées par CISAOracle JRE Remote Code Execution VulnerabilityA vulnerability in the way Java restricts the permissions of Java applets could allow an attacker to execute commands on a vulnerable system.
|
|
|
| CVE-2013-0431 | Oracle Java Runtime Environment (JRE) Notice et action publiées par CISAOracle JRE Sandbox Bypass VulnerabilityUnspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle allows remote attackers to bypass the Java security sandbox.
|
|
|
| CVE-2013-2423 | Oracle Java Runtime Environment (JRE) Notice et action publiées par CISAOracle JRE Unspecified VulnerabilityUnspecified vulnerability in hotspot for Java Runtime Environment (JRE) allows remote attackers to affect integrity.
|
|
|
| CVE-2013-3896 CWE-20 | Microsoft Silverlight Notice et action publiées par CISAMicrosoft Silverlight Information Disclosure VulnerabilityMicrosoft Silverlight does not properly validate pointers during access to Silverlight elements, which allows remote attackers to obtain sensitive information via a crafted Silverlight application.
|
|
|
| CVE-2013-3993 CWE-264 | IBM InfoSphere BigInsights Notice et action publiées par CISAIBM InfoSphere BigInsights Invalid Input VulnerabilityCertain APIs within BigInsights can take invalid input that might allow attackers unauthorized access to read, write, modify, or delete data.
|
|
|
| CVE-2013-7331 CWE-200 | Microsoft Internet Explorer Notice et action publiées par CISAMicrosoft Internet Explorer Information Disclosure VulnerabilityAn information disclosure vulnerability exists in Internet Explorer which allows resources loaded into memory to be queried. This vulnerability could allow an attacker to detect anti-malware applications.
|
|
|
| CVE-2014-0546 | Adobe Reader and Acrobat Notice et action publiées par CISAAdobe Reader and Acrobat Sandbox Bypass VulnerabilityAdobe Reader and Acrobat on Windows allow attackers to bypass a sandbox protection mechanism, and consequently execute native code in a privileged context.
|
|
|
| CVE-2014-2817 CWE-264 | Microsoft Internet Explorer Notice et action publiées par CISAMicrosoft Internet Explorer Privilege Escalation VulnerabilityMicrosoft Internet Explorer cotains an unspecified vulnerability that allows remote attackers to gain privileges via a crafted web site.
|
|
|
| CVE-2014-3153 CWE-269 | Linux Kernel Notice et action publiées par CISALinux Kernel Privilege Escalation VulnerabilityThe futex_requeue function in kernel/futex.c in Linux kernel does not ensure that calls have two different futex addresses, which allows local users to gain privileges.
|
|
|
| CVE-2014-4077 CWE-264 | Microsoft Input Method Editor (IME) Japanese Notice et action publiées par CISAMicrosoft IME Japanese Privilege Escalation VulnerabilityMicrosoft Input Method Editor (IME) Japanese is a keyboard with Japanese characters that can be enabled on Windows systems as it is included by default (with the default set as disabled). IME Japanese contains an unspecified vulnerability when IMJPDCT.EXE (IME for Japanese) is installed which allows attackers to bypass a sandbox and perform privilege escalation.
|
|
|
| CVE-2014-4123 CWE-264 | Microsoft Internet Explorer Notice et action publiées par CISAMicrosoft Internet Explorer Privilege Escalation VulnerabilityMicrosoft Internet Explorer contains an unspecified vulnerability that allows remote attackers to gain privileges via a crafted web site.
|
|
|
| CVE-2014-4148 CWE-94 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows Remote Code Execution VulnerabilityA remote code execution vulnerability exists when the Windows kernel-mode driver improperly handles TrueType fonts.
|
|
|
| CVE-2014-8439 CWE-119 | Adobe Flash Player Notice et action publiées par CISAAdobe Flash Player Dereferenced Pointer VulnerabilityAdobe Flash Player has a vulnerability in the way it handles a dereferenced memory pointer which could lead to code execution.
|
|
|
| CVE-2015-0016 CWE-22 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows TS WebProxy Directory Traversal VulnerabilityDirectory traversal vulnerability in the TS WebProxy (TSWbPrxy) component in Microsoft Windows allows remote attackers to escalate privileges.
|
|
|
| CVE-2015-0071 CWE-264 | Microsoft Internet Explorer Notice et action publiées par CISAMicrosoft Internet Explorer ASLR Bypass VulnerabilityMicrosoft Internet Explorer allows remote attackers to bypass the address space layout randomization (ASLR) protection mechanism via a crafted web site.
|
|
|
| CVE-2015-0310 CWE-264 | Adobe Flash Player Notice et action publiées par CISAAdobe Flash Player ASLR Bypass VulnerabilityAdobe Flash Player does not properly restrict discovery of memory addresses, which allows attackers to bypass the address space layout randomization (ASLR) protection mechanism.
|
|
|
Un ancien identifiant peut entrer récemment dans le catalogue
CVE-2015-5477, associée à ISC BIND dans cet instantané, porte une année 2015 et une dateAdded au 8 octobre 2026. Ces deux dates répondent à des questions différentes. La notice demande de suivre les instructions fournisseur ; elle ne prouve ni votre version de BIND, ni votre exposition, ni l’installation d’une correction.
Du signal public à une décision documentée
- Qualifier le rapprochement
Conserver CVE, source et date, puis identifier produit, version, composant embarqué et périmètre d’exposition. Une SBOM peut aider à trouver un composant sans prouver son état à l’exécution.
- Lire l’action à sa source
Ouvrir l’avis fournisseur et ses mises à jour. Séparer mise à jour, mitigation, arrêt d’un produit et recherche d’indices de compromission ; un correctif ne remplace pas ces autres décisions.
- Documenter le changement
Nommer un responsable, préparer le retour arrière et vérifier les dépendances. Une mitigation reste une mesure située, avec son périmètre et sa durée de validité.
- Vérifier l’état obtenu
Conserver une version observée, une configuration vérifiée et un test du service. Fermer une tâche demande une preuve portant sur l’actif réellement concerné, pas seulement un statut dans une console.
Publication de la source : · Consultation documentaire :
- CISA · KEV official snapshot · 2026.11.06
- CISA · KEV data schema · JSON Schema Draft 07 · pinned source
- CISA · Official mirror and reuse terms · Official repository · pinned source
- CISA · KEV licence · CC0 1.0 Universal
- FIRST · CVSS · CVSS 4.0
- FIRST · EPSS · Living documentation · reviewed 2026-10-22
Données CISA KEV réutilisées sous CC0 1.0. Cette réutilisation ne vaut ni affiliation ni approbation par CISA et n’autorise pas l’usage de son logo ou du sceau DHS.
Informations documentaires · CISA KEV
Comment nous publions cet instantané officiel
La copie est identifiée par la version du catalogue, sa dateReleased, le commit du miroir officiel et l’empreinte du fichier source. La publication CISA, la synchronisation GitHub et notre consultation sont trois événements distincts. Les regroupements sont recalculés sur les notices conservées ; aucune collecte de l’inventaire ou analyse de vulnérabilité du visiteur n’a lieu.
- catalogVersion
2026.11.06- dateReleased
- GitHub commit
e5b3a9b25050a8da26c96266c5bfe438ee0bdebc·- SHA-256
47e0406b2be5a40420eff66f3d90e83eb8883dae6ff4d08e1b2a942c366f6cc2
Les compteurs décrivent uniquement cet instantané. Ils ne mesurent ni le nombre d’attaques, ni la prévalence des vulnérabilités, ni le risque d’une organisation. Les libellés vendorProject sont comptés tels que publiés, sans fusion d’alias et sans les assimiler à autant d’entreprises.
Consulter le catalogue et sa méthode →
Publication de la source : · Consultation documentaire :
- CISA · KEV official snapshot · 2026.11.06
- CISA · KEV data schema · JSON Schema Draft 07 · pinned source
- CISA · Official mirror and reuse terms · Official repository · pinned source
- CISA · KEV licence · CC0 1.0 Universal
- FIRST · CVSS · CVSS 4.0
- FIRST · EPSS · Living documentation · reviewed 2026-10-22
Données CISA KEV réutilisées sous CC0 1.0. Cette réutilisation ne vaut ni affiliation ni approbation par CISA et n’autorise pas l’usage de son logo ou du sceau DHS.
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
- NIST SP 800-40 Rev. 4 — enterprise patch management
- CISA — Known Exploited Vulnerabilities Catalog
- FIRST · CVSS
- FIRST · EPSS
- CISA · Known Exploited Vulnerabilities
- SLSA 1.2 · Build: Verifying artifacts
- SLSA 1.2 · Build: Provenance
- SLSA 1.2 · Build: Track Basics
- in-toto · Statement v1
- Sigstore · Verifying Signatures
- CISA · KEV official snapshot
- CISA · KEV data schema
- CISA · Official mirror and reuse terms
- CISA · KEV licence
- FIRST · CVSS
- FIRST · EPSS Frequently Asked Questions
- CISA · KEV official data schema
- OpenVEX · Specification v0.2.0
Pour aller plus loin
Analyses associées
