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 : 1769 / 1769 · Page 22 / 71
| CVE | Fournisseur ou projet · product | Date d’entrée / Échéance de la notice | Usage dans des campagnes de rançongiciel / forensicTriage |
|---|---|---|---|
| CVE-2024-12686 CWE-78 | BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) Notice et action publiées par CISABeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) OS Command Injection VulnerabilityBeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) contain an OS command injection vulnerability that can be exploited by an attacker with existing administrative privileges to upload a malicious file. Successful exploitation of this vulnerability can allow a remote attacker to execute underlying operating system commands within the context of the site user.
|
|
|
| CVE-2025-0282 CWE-121 | Ivanti Connect Secure, Policy Secure, and ZTA Gateways Notice et action publiées par CISAIvanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow VulnerabilityIvanti Connect Secure, Policy Secure, and ZTA Gateways contain a stack-based buffer overflow which can lead to unauthenticated remote code execution.
|
|
|
| CVE-2020-2883 | Oracle WebLogic Server Notice et action publiées par CISAOracle WebLogic Server Unspecified VulnerabilityOracle WebLogic Server, a product within the Fusion Middleware suite, contains an unspecified vulnerability exploitable by an unauthenticated attacker with network access via IIOP or T3.
|
|
|
| CVE-2024-41713 CWE-22 | Mitel MiCollab Notice et action publiées par CISAMitel MiCollab Path Traversal VulnerabilityMitel MiCollab contains a path traversal vulnerability that could allow an attacker to gain unauthorized and unauthenticated access. This vulnerability can be chained with CVE-2024-55550, which allows an unauthenticated, remote attacker to read arbitrary files on the server.
|
|
|
| CVE-2024-55550 CWE-22 | Mitel MiCollab Notice et action publiées par CISAMitel MiCollab Path Traversal VulnerabilityMitel MiCollab contains a path traversal vulnerability that could allow an authenticated attacker with administrative privileges to read local files within the system due to insufficient input sanitization. This vulnerability can be chained with CVE-2024-41713, which allows an unauthenticated, remote attacker to read arbitrary files on the server.
|
|
|
| CVE-2024-3393 CWE-754 | Palo Alto Networks PAN-OS Notice et action publiées par CISAPalo Alto Networks PAN-OS Malicious DNS Packet VulnerabilityPalo Alto Networks PAN-OS contains a vulnerability in parsing and logging malicious DNS packets in the DNS Security feature that, when exploited, allows an unauthenticated attacker to remotely reboot the firewall. Repeated attempts to trigger this condition will cause the firewall to enter maintenance mode.
|
|
|
| CVE-2021-44207 CWE-798 | Acclaim Systems USAHERDS Notice et action publiées par CISAAcclaim Systems USAHERDS Use of Hard-Coded Credentials VulnerabilityAcclaim Systems USAHERDS contains a hard-coded credentials vulnerability that could allow an attacker to achieve remote code execution on the system that runs the application. The MachineKey must be obtained via a separate vulnerability or other channel.
|
|
|
| CVE-2024-12356 CWE-77 | BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) Notice et action publiées par CISABeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) Command Injection VulnerabilityBeyondTrust Privileged Remote Access (PRA) and Remote Support (RS) contain a command injection vulnerability, which can allow an unauthenticated attacker to inject commands that are run as a site user.
|
|
|
| CVE-2018-14933 CWE-78 | NUUO NVRmini Devices Notice et action publiées par CISANUUO NVRmini Devices OS Command Injection VulnerabilityNUUO NVRmini devices contain an OS command injection vulnerability. This vulnerability allows remote command execution via shell metacharacters in the uploaddir parameter for a writeuploaddir command.
|
|
|
| CVE-2019-11001 CWE-78 | Reolink Multiple IP Cameras Notice et action publiées par CISAReolink Multiple IP Cameras OS Command Injection VulnerabilityReolink RLC-410W, C1 Pro, C2 Pro, RLC-422W, and RLC-511W IP cameras contain an authenticated OS command injection vulnerability. This vulnerability allows an authenticated admin to use the "TestEmail" functionality to inject and run OS commands as root.
|
|
|
| CVE-2021-40407 CWE-78 | Reolink RLC-410W IP Camera Notice et action publiées par CISAReolink RLC-410W IP Camera OS Command Injection VulnerabilityReolink RLC-410W IP cameras contain an authenticated OS command injection vulnerability in the device network settings functionality.
|
|
|
| CVE-2022-23227 CWE-306 | NUUO NVRmini2 Devices Notice et action publiées par CISANUUO NVRmini2 Devices Missing Authentication VulnerabilityNUUO NVRmini2 devices contain a missing authentication vulnerability that allows an unauthenticated attacker to upload an encrypted TAR archive, which can be abused to add arbitrary users.
|
|
|
| CVE-2024-55956 CWE-276 | Cleo Multiple Products Notice et action publiées par CISACleo Multiple Products Unauthenticated File Upload VulnerabilityCleo Harmony, VLTrader, and LexiCom, which are managed file transfer products, contain an unrestricted file upload vulnerability that could allow an unauthenticated user to import and execute arbitrary bash or PowerShell commands on the host system by leveraging the default settings of the Autorun directory.
|
|
|
| CVE-2024-20767 CWE-284 | Adobe ColdFusion Notice et action publiées par CISAAdobe ColdFusion Improper Access Control VulnerabilityAdobe ColdFusion contains an improper access control vulnerability that could allow an attacker to access or modify restricted files via an internet-exposed admin panel.
|
|
|
| CVE-2024-35250 CWE-822 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows Kernel-Mode Driver Untrusted Pointer Dereference VulnerabilityMicrosoft Windows Kernel-Mode Driver contains an untrusted pointer dereference vulnerability that allows a local attacker to escalate privileges.
|
|
|
| CVE-2024-50623 CWE-434 | Cleo Multiple Products Notice et action publiées par CISACleo Multiple Products Unrestricted File Upload VulnerabilityCleo Harmony, VLTrader, and LexiCom, which are managed file transfer products, contain an unrestricted file upload and download vulnerability that can lead to remote code execution with elevated privileges.
|
|
|
| CVE-2024-49138 CWE-122 | Microsoft Windows Notice et action publiées par CISAMicrosoft Windows Common Log File System (CLFS) Driver Heap-Based Buffer Overflow VulnerabilityMicrosoft Windows Common Log File System (CLFS) driver contains a heap-based buffer overflow vulnerability that allows a local attacker to escalate privileges.
|
|
|
| CVE-2024-51378 CWE-276 | CyberPersons CyberPanel Notice et action publiées par CISACyberPanel Incorrect Default Permissions VulnerabilityCyberPanel contains an incorrect default permissions vulnerability that allows for authentication bypass and the execution of arbitrary commands using shell metacharacters in the statusfile property.
|
|
|
| CVE-2023-45727 CWE-611 | North Grid Proself Notice et action publiées par CISANorth Grid Proself Improper Restriction of XML External Entity (XXE) Reference VulnerabilityNorth Grid Proself Enterprise/Standard, Gateway, and Mail Sanitize contain an improper restriction of XML External Entity (XXE) reference vulnerability, which could allow a remote, unauthenticated attacker to conduct an XXE attack.
|
|
|
| CVE-2024-11667 CWE-22 | Zyxel Multiple Firewalls Notice et action publiées par CISAZyxel Multiple Firewalls Path Traversal VulnerabilityMultiple Zyxel firewalls contain a path traversal vulnerability in the web management interface that could allow an attacker to download or upload files via a crafted URL.
|
|
|
| CVE-2024-11680 CWE-287 | ProjectSend ProjectSend Notice et action publiées par CISAProjectSend Improper Authentication VulnerabilityProjectSend contains an improper authentication vulnerability that allows a remote, unauthenticated attacker to enable unauthorized modification of the application's configuration via crafted HTTP requests to options.php. Successful exploitation allows attackers to create accounts, upload webshells, and embed malicious JavaScript.
|
|
|
| CVE-2023-28461 CWE-306 | Array Networks AG/vxAG ArrayOS Notice et action publiées par CISAArray Networks AG and vxAG ArrayOS Missing Authentication for Critical Function VulnerabilityArray Networks AG and vxAG ArrayOS contain a missing authentication for critical function vulnerability that allows an attacker to read local files and execute code on the SSL VPN gateway.
|
|
|
| CVE-2024-21287 CWE-863 | Oracle Agile Product Lifecycle Management (PLM) Notice et action publiées par CISAOracle Agile Product Lifecycle Management (PLM) Incorrect Authorization VulnerabilityOracle Agile Product Lifecycle Management (PLM) contains an incorrect authorization vulnerability in the Process Extension component of the Software Development Kit. Successful exploitation of this vulnerability may result in unauthenticated file disclosure.
|
|
|
| CVE-2024-44308 | Apple Multiple Products Notice et action publiées par CISAApple Multiple Products Code Execution VulnerabilityApple iOS, macOS, and other Apple products contain an unspecified vulnerability when processing maliciously crafted web content that may lead to arbitrary code execution.
|
|
|
| CVE-2024-44309 CWE-79 | Apple Multiple Products Notice et action publiées par CISAApple Multiple Products Cross-Site Scripting (XSS) VulnerabilityApple iOS, macOS, and other Apple products contain an unspecified vulnerability when processing maliciously crafted web content that may lead to a cross-site scripting (XSS) attack.
|
|
|
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
