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 : 186 / 1769 · Page 3 / 8
| CVE | Fournisseur ou projet · product | Date d’entrée / Échéance de la notice | Usage dans des campagnes de rançongiciel / forensicTriage |
|---|---|---|---|
| CVE-2024-43047 CWE-416 | Qualcomm Multiple Chipsets Notice et action publiées par CISAQualcomm Multiple Chipsets Use-After-Free VulnerabilityMultiple Qualcomm chipsets contain a use-after-free vulnerability due to memory corruption in DSP Services while maintaining memory maps of HLOS memory.
|
|
|
| CVE-2024-43572 CWE-707 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows Management Console Remote Code Execution VulnerabilityMicrosoft Windows Management Console contains unspecified vulnerability that allows for remote code execution.
|
|
|
| CVE-2024-43573 CWE-79 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows MSHTML Platform Spoofing VulnerabilityMicrosoft Windows MSHTML Platform contains an unspecified spoofing vulnerability which can lead to a loss of confidentiality.
|
|
|
| CVE-2024-45519 CWE-284 | Synacor Zimbra Collaboration Suite (ZCS) Notice et action publiées par CISASynacor Zimbra Collaboration Suite (ZCS) Command Execution VulnerabilitySynacor Zimbra Collaboration Suite (ZCS) contains an unspecified vulnerability in the postjournal service that may allow an unauthenticated user to execute commands.
|
|
|
| CVE-2024-29824 CWE-89 | Ivanti Endpoint Manager (EPM) Notice et action publiées par CISAIvanti Endpoint Manager (EPM) SQL Injection VulnerabilityIvanti Endpoint Manager (EPM) contains a SQL injection vulnerability in Core server that allows an unauthenticated attacker within the same network to execute arbitrary code.
|
|
|
| CVE-2019-0344 CWE-502 | SAP Commerce Cloud Notice et action publiées par CISASAP Commerce Cloud Deserialization of Untrusted Data VulnerabilitySAP Commerce Cloud (formerly known as Hybris) contains a deserialization of untrusted data vulnerability within the mediaconversion and virtualjdbc extension that allows for code injection.
|
|
|
| CVE-2020-15415 CWE-78 | DrayTek Multiple Vigor Routers Notice et action publiées par CISADrayTek Multiple Vigor Routers OS Command Injection VulnerabilityDrayTek Vigor3900, Vigor2960, and Vigor300B devices contain an OS command injection vulnerability in cgi-bin/mainfunction.cgi/cvmcfgupload that allows for remote code execution via shell metacharacters in a filename when the text/x-python-script content type is used.
|
|
|
| CVE-2023-25280 CWE-78 | D-Link DIR-820 Router Notice et action publiées par CISAD-Link DIR-820 Router OS Command Injection VulnerabilityD-Link DIR-820 routers contain an OS command injection vulnerability that allows a remote, unauthenticated attacker to escalate privileges to root via a crafted payload with the ping_addr parameter to ping.ccp.
|
|
|
| CVE-2024-7593 CWE-287, CWE-303 | Ivanti Virtual Traffic Manager Notice et action publiées par CISAIvanti Virtual Traffic Manager Authentication Bypass VulnerabilityIvanti Virtual Traffic Manager contains an authentication bypass vulnerability that allows a remote, unauthenticated attacker to create a chosen administrator account.
|
|
|
| CVE-2024-8963 CWE-22 | Ivanti Cloud Services Appliance (CSA) Notice et action publiées par CISAIvanti Cloud Services Appliance (CSA) Path Traversal VulnerabilityIvanti Cloud Services Appliance (CSA) contains a path traversal vulnerability that could allow a remote, unauthenticated attacker to access restricted functionality. If CVE-2024-8963 is used in conjunction with CVE-2024-8190, an attacker could bypass admin authentication and execute arbitrary commands on the appliance.
|
|
|
| CVE-2020-0618 CWE-502 | Microsoft SQL Server Notice et action publiées par CISAMicrosoft SQL Server Reporting Services Remote Code Execution VulnerabilityMicrosoft SQL Server Reporting Services contains a deserialization vulnerability when handling page requests incorrectly. An authenticated attacker can exploit this vulnerability to execute code in the context of the Report Server service account.
|
|
|
| CVE-2020-14644 | Oracle WebLogic Server Notice et action publiées par CISAOracle WebLogic Server Remote Code Execution VulnerabilityOracle WebLogic Server, a product within the Fusion Middleware suite, contains a deserialization vulnerability. Unauthenticated attackers with network access via T3 or IIOP can exploit this vulnerability to achieve remote code execution.
|
|
|
| CVE-2022-21445 CWE-502 | Oracle ADF Faces Notice et action publiées par CISAOracle ADF Faces Deserialization of Untrusted Data VulnerabilityOracle ADF Faces library, included with Oracle JDeveloper Distribution, contains a deserialization of untrusted data vulnerability leading to unauthenticated remote code execution.
|
|
|
| CVE-2024-27348 CWE-284 | Apache HugeGraph-Server Notice et action publiées par CISAApache HugeGraph-Server Improper Access Control VulnerabilityApache HugeGraph-Server contains an improper access control vulnerability that could allow a remote attacker to execute arbitrary code.
|
|
|
| CVE-2013-0643 CWE-264 | Adobe Flash Player Notice et action publiées par CISAAdobe Flash Player Incorrect Default Permissions VulnerabilityAdobe Flash Player contains an incorrect default permissions vulnerability in the Firefox sandbox that allows a remote attacker to execute arbitrary code via crafted SWF content.
|
|
|
| CVE-2013-0648 | Adobe Flash Player Notice et action publiées par CISAAdobe Flash Player Code Execution VulnerabilityAdobe Flash Player contains an unspecified vulnerability in the ExternalInterface ActionScript functionality that allows a remote attacker to execute arbitrary code via crafted SWF content.
|
|
|
| CVE-2014-0497 CWE-191 | Adobe Flash Player Notice et action publiées par CISAAdobe Flash Player Integer Underflow VulnerablityAdobe Flash Player contains an integer underflow vulnerability that allows a remote attacker to execute arbitrary code.
|
|
|
| CVE-2014-0502 CWE-399 | Adobe Flash Player Notice et action publiées par CISAAdobe Flash Player Double Free VulnerablityAdobe Flash Player contains a double free vulnerability that allows a remote attacker to execute arbitrary code.
|
|
|
| CVE-2024-43461 CWE-451 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows MSHTML Platform Spoofing VulnerabilityMicrosoft Windows MSHTML Platform contains a user interface (UI) misrepresentation of critical information vulnerability that allows an attacker to spoof a web page. This vulnerability was exploited in conjunction with CVE-2024-38112.
|
|
|
| CVE-2024-6670 CWE-89 | Progress WhatsUp Gold Notice et action publiées par CISAProgress WhatsUp Gold SQL Injection VulnerabilityProgress WhatsUp Gold contains a SQL injection vulnerability that allows an unauthenticated attacker to retrieve the user's encrypted password if the application is configured with only a single user.
|
|
|
| CVE-2024-8190 CWE-78 | Ivanti Cloud Services Appliance Notice et action publiées par CISAIvanti Cloud Services Appliance OS Command Injection VulnerabilityIvanti Cloud Services Appliance (CSA) contains an OS command injection vulnerability in the administrative console which can allow an authenticated attacker with application admin privileges to pass commands to the underlying OS.
|
|
|
| CVE-2024-38014 CWE-269 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows Installer Improper Privilege Management VulnerabilityMicrosoft Windows Installer contains an improper privilege management vulnerability that could allow an attacker to gain SYSTEM privileges.
|
|
|
| CVE-2024-38217 CWE-693 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows Mark of the Web (MOTW) Protection Mechanism Failure VulnerabilityMicrosoft Windows Mark of the Web (MOTW) contains a protection mechanism failure vulnerability that allows an attacker to bypass MOTW-based defenses. This can result in a limited loss of integrity and availability of security features such as Protected View in Microsoft Office, which rely on MOTW tagging.
|
|
|
| CVE-2024-38226 CWE-693 | Microsoft Publisher Notice et action publiées par CISAMicrosoft Publisher Protection Mechanism Failure VulnerabilityMicrosoft Publisher contains a protection mechanism failure vulnerability that allows attacker to bypass Office macro policies used to block untrusted or malicious files.
|
|
|
| CVE-2016-3714 CWE-20 | ImageMagick ImageMagick Notice et action publiées par CISAImageMagick Improper Input Validation VulnerabilityImageMagick contains an improper input validation vulnerability that affects the EPHEMERAL, HTTPS, MVG, MSL, TEXT, SHOW, WIN, and PLT coders. This allows a remote attacker to execute arbitrary code via shell metacharacters in a crafted image.
|
|
|
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
