Vulnérabilités non corrigées : risques, causes et solutions

Principaux enseignements

• Une vulnérabilité non corrigée dispose d'un correctif qui n'a tout simplement pas encore été appliqué.
• Le rapport « M-Trends 2026 » de Mandiant estime que le délai moyen d'exploitation est de moins sept jours ; en moyenne, les pirates parviennent donc à contourner le correctif avant sa mise en place.
• Le rapport DBIR 2026 de Verizon a révélé que seules 26 % des vulnérabilités KEV détectées avaient été entièrement corrigées, le délai médian pour y parvenir s'élevant à 43 jours.

La plupart des équipes de sécurité ont le même arriéré. Celui-ci comprend les CVE qui ont été triées, enregistrées sous forme de tickets, programmées, puis discrètement reportées parce que la fenêtre de maintenance coïncidait avec la clôture de fin de trimestre. Il s'agit là de vulnérabilités non corrigées, et leur exploitation est devenue le principal moyen connu utilisé par les attaquants pour obtenir un accès initial.

L'écart qui compte, c'est celui qui existe entre le moment où un correctif est disponible et celui où il est effectivement déployé en production. La suite de cet article explique pourquoi cet écart persiste et comment le combler.

Qu'est-ce qui est considéré comme une vulnérabilité non corrigée ?

Une vulnérabilité non corrigée est une faille connue pour laquelle un correctif est disponible, mais qui persiste sur un système où ce correctif n'a pas été appliqué. Trois éléments, tous indispensables : une faille connue, un correctif disponible et un système qui ne l'a toujours pas installé.

C'est justement cette partie centrale, la solution proposée, qui la distingue de ses deux voisines.

Une faille « zero-day » est exploitée avant que les défenseurs n’aient eu une chance raisonnable de réagir, généralement avant sa divulgation ou avant qu’un correctif n’existe. En attendant la publication d’un correctif, les mesures d’atténuation sont votre seul recours. Notre analyse de la manière dont notre travail sur les couvre ce cas de figure.

Logiciel en fin de vie est l'autre voisin. Des correctifs sont possibles, mais l'éditeur d'origine a cessé de les fournir. CentOS 7, PostgreSQL 13, une branche PHP en fin de vie – de véritables vulnérabilités CVE, une exposition réelle, aucune prise en charge en amont.

Sur le papier, cette vulnérabilité non corrigée est la plus facile à éviter parmi les trois, puisque le correctif existe déjà et est généralement gratuit. Dans la pratique, un correctif gratuit implique tout de même un temps de test et une fenêtre de maintenance, ce qui constitue la moitié du sujet de cet article.

Le délai entre la divulgation d'une faille et son exploitation est plus court que ne le laissent supposer la plupart des calendriers de correctifs, et il ne se déroule pas toujours dans l'ordre.

Stade	Quand cela arrive	Que se passe-t-il ?
Vulnérabilité CVE révélée, correctif publié	Le jour même ou à quelques semaines d'intervalle	Souvent associés dans le cadre d'une évaluation critique de la RCE
Preuve de concept (PoC) publique ou code d'exploitation	À tout moment, depuis la période précédant la divulgation jusqu'à plusieurs semaines après celle-ci	GitHub, frameworks d'exploitation, rapports de recherche
Analyse massive du Web	Quelques heures après la mise au point d'un prototype fonctionnel	Les pirates identifient à grande échelle les instances exposées
Exploitation active, inscription au KEV	Elle peut débuter avant la publication de l'information, et l'inscription au registre KEV intervient après confirmation par la CISA.	Il s'agit désormais d'un vecteur d'attaque confirmé et activement utilisé

La gravité et la probabilité d'exploitation sont deux indicateurs distincts. Un score CVSS de 9,8 sur un service que vous ne rendez pas accessible peut s'avérer moins dangereux qu'un score CVSS de 6,5 sur votre périphérie. Consultez notre guide pratique sur les changements apportés à la version 4.0 du CVSS.

Le coût réel des failles de sécurité non corrigées

Commençons par un chiffre que vous devriez cesser de répéter : «les vulnérabilités non corrigées sont à l’origine de 60 % des violations de données». Ce chiffre provient d’une enquête réalisée en 2019 par le Ponemon Institute pour le compte de ServiceNow, et il ne devrait plus être cité comme un chiffre actuel valable pour l’ensemble du secteur.

Les données actuelles brossent un tableau plus précis. Selon le rapport DBIR 2026 de Verizon, 31 % des violations de données ont commencé par l’exploitation d’une vulnérabilité, contre 20 % l’année précédente. Cela en a fait le principal vecteur d’accès initial connu dans l’ensemble de données de Verizon, pour la première fois depuis la création du rapport. Les violations de données sont également devenues plus coûteuses. Le rapport 2026 d’IBM sur le coût d’une violation de données estime le coût moyen d'une violation à l'échelle mondiale à 4,99 millions de dollars, un record.

Les ransomwares font figure d'exception. Selon l'enquête « State of Ransomware 2026 » menée par Sophos, seuls 18 % des victimes de ransomware ont pu attribuer l’attaque à l’exploitation d’une vulnérabilité, contre 32 % l’année précédente, les e-mails malveillants et le phishing étant désormais les principales causes. L’application des correctifs reste importante dans ce domaine. Mais ce n’est tout simplement plus la seule porte d’entrée.

Ces dommages se traduisent par des risques réglementaires, des demandes de rançon, des temps d’arrêt, des constatations de non-conformité et des répercussions sur la réputation qui perdurent bien au-delà de tout cela. Notre analyse des coûts réels liés au fait de ne pas appliquer de correctif à une vulnérabilité CVE critique approfondit chacun de ces aspects.

Trois cas de violation illustrent comment cela se passe, chacun à sa manière.

Incident	CVE	Correctif disponible	Exploitation	Retombées
Equifax	CVE-2017-5638 (Apache Struts 2)	Mars 7, 2017	Le portail a été analysé et une vulnérabilité a été détectée le 10 mars 2017 ; des données personnelles ont été consultées à partir du 13 mai, et la violation a été détectée le 29 juillet.	147 millions de personnes, auxquelles s'ajoute un accord entre la FTC, le CFPB et les États d'un montant d'au moins 575 millions de dollars
MOVEit Transfer	34362	Mai 31, 2023	L'exploitation massive de la faille Cl0p, considérée comme une faille « zero-day », s'est produite du 27 au 28 mai 2023, et les serveurs non mis à jour ont continué à être touchés pendant plusieurs semaines par la suite.	2 773 organisations, soit environ 95,8 millions de personnes (Emsisoft)
Log4Shell	44228	Log4j 2.15.0, 10 décembre 2021, suivi de correctifs quelques jours plus tard	Analyse datée du 1er décembre 2021 : exploitation massive quelques heures seulement après la divulgation	Près de 40 millions de téléchargements de versions vulnérables de Log4j rien qu’en 2025, soit environ 13 % du total de cette année-là (Sonatype)

Equifax illustre parfaitement le cas d'une vulnérabilité non corrigée. Le correctif a été publié le 7 mars ; trois jours plus tard, des pirates testaient déjà le portail, et le vol massif de données a commencé 67 jours après la mise à disposition du correctif. Les incidents MOVEit et Log4Shell ont d'abord été des failles « zero-day », puis se sont presque immédiatement transformés en cas de vulnérabilités non corrigées, dès lors que des correctifs existaient et que de nombreuses installations continuaient malgré tout à utiliser la version vulnérable.

Pourquoi certaines vulnérabilités ne sont pas corrigées (les raisons que les équipes admettent rarement)

Chacune de ces décisions est rationnelle et prise au niveau local, mais elles aboutissent à un résultat irrationnel à l'échelle de l'ensemble de l'organisation.

Motif	À quoi ça ressemble ?	Qu'est-ce qui permet de l'éliminer ?
La crainte des temps d'arrêt	Le noyau CVE nécessite un redémarrage, et l'hôte est de type « stateful » sans basculement	Corrections du noyau sans redémarrage
Logiciel en fin de vie, aucun correctif en amont	Serveur CentOS 7 exécutant une application qui ne peut pas être compilée sur une version plus récente	Une extension de la prise en charge assurée par le fournisseur, ou une date de migration financée
Des correctifs qui ne voient jamais le jour	L'automatisation affiche un taux de réussite de 98 %. Les 2 % restants sont dans une situation précaire.	Rapprochement entre les données issues des outils de correction et celles issues des numérisations indépendantes
Actifs non identifiés	Une machine virtuelle de préproduction de 2021, un conteneur d'un sous-traitant, un sous-domaine oublié	Détection continue et permanente
Coûts liés aux tests	Chaque correctif fait l'objet de tests de régression sur un monolithe que personne ne comprend vraiment	Tests classés par niveau de risque, avec mise en œuvre accélérée des correctifs de sécurité critiques grâce à des déploiements progressifs
Il y a plus de CVE que de temps disponible pour le triage	48 185 CVE publiées en 2025. Trois personnes ne peuvent pas lire ce chiffre.	Filtrage basé sur l'exploitabilité

 Le volume à lui seul est une raison suffisante. Le chercheur en sécurité Jerry Gamblin, qui a analysé les données CVE de 2025, a recensé 48 185 enregistrements publiés, soit environ 132 par jour, tandis que la page EPSS de FIRST indique que seul un faible pourcentage à un chiffre des CVE publiées est exploité au cours d’une période donnée de 30 jours. La plupart des vulnérabilités en attente ne feront pas l’objet d’une attaque ce mois-ci. Le plus difficile est de savoir lesquelles le seront.

Vient ensuite l’accumulation. Les correctifs reportés s’accumulent pour former une « dette de sécurité », tout comme les refactorisations reportées s’accumulent pour former une « dette technique », et les conséquences se manifestent sous la forme d’un incident. Le « bruit » des scanners aggrave encore la situation, car les équipes qui passent des semaines à traquer un faux positif perdent la crédibilité dont elles ont besoin lorsqu’un véritable incident survient. Le statut de « fin de vie » d’un système d’exploitation s'inscrit dans cette même boucle de découverte continue.

Dans les entreprises de taille moyenne, le scénario le plus courant n’est pas qu’une équipe décide de ne pas appliquer de correctifs. Il s’agit plutôt d’un outil d’orchestration qui signale que tout fonctionne correctement sur un hôte dont l’agent de gestion de configuration s’est discrètement désinstallé plusieurs mois auparavant. Personne n’a menti. C’est la couche de reporting qui a mesuré le mauvais indicateur.

Comment les pirates exploitent les failles non corrigées

Mettez-vous à la place de l’attaquant. Une faille « zero-day » coûte du temps de recherche, ou plusieurs centaines de milliers d’euros sur un marché de courtage. Une faille « n-day », c’est-à-dire une faille pour laquelle un correctif public existe, peut coûter à peine plus cher qu’une requête Shodan, à condition qu’il y ait une preuve de concept fonctionnelle et suffisamment de cibles exposées vers lesquelles la diriger. Les attaquants ont recours aux failles « zero-day » lorsqu’ils y sont contraints et aux failles « n-day » dès qu’ils le peuvent, et le processus de divulgation réapprovisionne chaque jour le stock de failles « n-day ».

Le rapport « M-Trends 2026 » de Mandiant chiffre précisément l’ampleur de cette réduction. Le délai moyen avant exploitation est désormais estimé à moins sept jours, ce qui signifie qu’en moyenne, l’exploitation commence avant même la publication du correctif. Les exploits occupent la première place parmi les vecteurs d’infection initiaux les plus courants depuis six années consécutives, représentant désormais 32 % des intrusions pour lesquelles Mandiant a pu identifier le point d’entrée.

Le catalogue des vulnérabilités connues et exploitées de la CISA est le tableau de bord public répertoriant les failles qui sont passées du stade théorique à celui d’exploitation active, et il s’enrichit chaque semaine. Les délais qu’il impose aux agences civiles fédérales américaines ont changé en 2026. La directive BOD 22-01, qui, depuis 2021, accordait aux agences deux semaines pour corriger les entrées du catalogue KEV (six mois pour les CVE plus anciennes), a été remplacée, tout comme l’ancienne directive BOD 19-02, par la BOD 26-04, « Priorisation des mises à jour de sécurité en fonction des risques », publiée le 10 juin 2026.

Au lieu d’une échéance unique et fixe, la nouvelle directive évalue chaque vulnérabilité en fonction de quatre critères. L’actif est-il exposé au public ? La faille figure-t-elle dans la base KEV ? Son exploitation peut-elle être automatisée ? Permet-elle à un attaquant d’obtenir un contrôle total du système, ou seulement partiel ? Les réponses à ces questions déterminent le délai imparti. Les combinaisons les plus risquées bénéficient d’un délai de trois jours, et les cas KEV présentant le risque le plus élevé et impliquant un contrôle total nécessitent également un triage informatique afin de vérifier si le système a déjà été compromis. Tous les autres cas bénéficient d’un délai de 14 ou 60 jours, et les failles qui ne répondent à aucun des quatre critères peuvent attendre la prochaine mise à jour prévue de la ressource.

De nombreuses failles largement exploitées sont des vulnérabilités permettant l'exécution de code à distance dans des services connectés à Internet et des appareils périphériques ; parfois, le système vulnérable ne vous appartient même pas et vous ne pouvez donc pas y appliquer de correctif. MOVEit en est l'exemple récent le plus frappant. Une faille dans un logiciel de transfert de fichiers très répandu a entraîné des milliers de victimes en aval.

Pour les agences civiles fédérales, le délai maximal pour le niveau le plus grave est désormais fixé à trois jours, et un comité consultatif chargé d’évaluer les changements hebdomadaires ne peut pas l’atteindre. Si votre réponse la plus rapide possible à une vulnérabilité activement exploitée et exposée sur Internet RCE exposée à Internet et activement exploitée prend plus de trois jours, il s’agit là d’une lacune dans le processus qu’il convient de combler avant l’apparition de la prochaine vulnérabilité.

Comment éviter que les failles de sécurité non corrigées ne s'accumulent

Il s'agit d'un problème de processus comportant cinq éléments, et passer directement à la hiérarchisation des priorités avant d'avoir dressé un inventaire revient simplement à hiérarchiser un sous-ensemble dont on ne peut pas cerner pleinement les composantes.

Identifiez d'abord toutes les vulnérabilités non corrigées

Dans ce domaine, la couverture prime sur la sophistication. Un modèle de hiérarchisation parfait couvrant 70 % de votre patrimoine vous sera moins utile qu’un triage sommaire couvrant l’ensemble de celui-ci.

Constituez votre inventaire en abordant la question sous plusieurs angles, car chaque source présente des lacunes différentes. La gestion des configurations et l’inventaire des agents ne prennent pas en compte les éléments qui ne sont plus gérés par l’agent. Les API des fournisseurs de cloud ne détectent pas les systèmes sur site ni les comptes « fantômes ». L’analyse authentifiée du réseau ne repère pas les hôtes qui étaient hors tension pendant la période d’analyse. C’est la découverte des sous-domaines via le DNS et de la surface d’attaque externe qui permet de repérer le sous-domaine dont personne ne se souvient être propriétaire.

Procédez ensuite à une mise en concordance. C’est précisément là où ces listes divergent que réside l’intérêt. Un hôte qui figure dans votre inventaire cloud mais pas dans les résultats de votre analyseur de vulnérabilités représente exactement le type de lacune susceptible de vous exposer à une intrusion. Une fois que la liste des actifs est validée, recoupez les paquets installés et leurs versions sur chaque hôte avec les avis de sécurité qui s’y rapportent, afin d’identifier ceux qui sont réellement vulnérables.

Vérifiez également que les correctifs signalés ont bien été appliqués. Le fait qu’un paquet de noyau plus récent soit présent sur le disque ne signifie pas pour autant que le noyau en cours d’exécution est protégé. À moins que l’hôte n’ait redémarré avec ce paquet ou n’ait reçu un correctif en temps réel pour ce CVE, il s’agit d’une vulnérabilité portant la mention « corrigée ».

Hiérarchiser en fonction de l'exploitabilité réelle

Le nombre brut de CVE permet de mesurer la charge de travail. Pour évaluer le risque réel, il faut toutefois tenir compte de trois autres facteurs.

Commencez par KEV. Une mention dans cette liste signifie qu’une exploitation en milieu réel a été confirmée ; par conséquent, si cela concerne vos actifs, appliquez immédiatement le correctif, quel que soit le score CVSS. Vérifiez ensuite le score EPSS, une probabilité mise à jour quotidiennement (comprise entre 0 et 1) indiquant la probabilité qu’un CVE publié soit exploité en milieu réel au cours des 30 prochains jours. Ce service est gratuit, lisible par machine et conçu précisément pour prendre ce type de décision. Enfin, évaluez séparément l’exposition et l’importance métier. L’actif est-il exposé à Internet ou accessible depuis des systèmes sur lesquels un attaquant pourrait déjà se trouver ? Contient-il des données sensibles ou soumises à une réglementation ?

Les comparaisons réalisées par FIRST illustrent bien les gains d’efficacité. Une règle générale visant les vulnérabilités notées 7 ou plus selon le CVSS entraîne la mise en attente d’une part considérable de la file d’attente pour correction, tandis qu’un seuil défini par l’EPSS permet de détecter une grande partie des vulnérabilités réellement exploitées, pour un effort bien moindre. Il n’existe toutefois pas de seuil universel à reproduire. Le seuil approprié dépend de votre propre file d’attente.

Si votre équipe manque de ressources, commencez par le KEV et la surveillance, puis intégrez progressivement l'EPSS. Si vous appliquez déjà les correctifs KEV de manière fiable, l'EPSS constitue la prochaine étape dans la réduction des risques.

Apportez rapidement les correctifs et éliminez les causes du problème.

La rapidité résulte de la réduction des frictions dans le processus. Automatisez le déploiement afin que l'application des correctifs s'effectue selon un pipeline plutôt que sous la forme d'un projet ponctuel, car un correctif dont la planification nécessite une intervention humaine a tendance à être programmé trop tard.

Il faut alors s'attaquer directement au problème lié au redémarrage. Les redémarrages sont l'une des raisons les plus courantes pour lesquelles les correctifs du noyau ne sont pas appliqués. Ils imposent une fenêtre de maintenance, la création d'un ticket de modification et obligent quelqu'un à rester éveillé à 2 heures du matin pour vérifier que le serveur a bien redémarré. L'application de correctifs sans redémarrage, parfois appelée « correctifs à chaud », applique le correctif au noyau en cours d’exécution en mémoire ; ainsi, pour les vulnérabilités prises en charge, la faille est comblée sans interruption de service.

KernelCare fonctionne sur les principales distributions Linux d’entreprise ; ainsi, un environnement hétérogène n’a pas besoin d’un outil distinct pour chaque système d’exploitation, et les charges de travail fonctionnant 24 h/24 et 7 j/7 ne sacrifient plus la disponibilité au profit d’une exposition aux vulnérabilités CVE.

Couvrir les logiciels en fin de vie (EOL) pour lesquels aucun correctif n'est disponible auprès du fournisseur

Tout ce qui précède part du principe que le fournisseur propose toujours un correctif. Or, pour les composants en fin de vie, ce n'est pas le cas du fournisseur d'origine, et le conseil habituel consistant à simplement effectuer une mise à niveau ne tient pas compte de la raison pour laquelle le système fonctionne encore aujourd'hui.

En général, cela se résume à du matériel incompatible avec un noyau plus récent, à une application dont l’éditeur n’a certifié qu’une seule version du système d’exploitation, à une validation réglementaire qu’il faudrait refaire de zéro, ou à des ressources techniques déjà allouées pour les trois quarts de l’année à venir. Un e-mail sévère concernant les dates de fin de vie ne résout aucun de ces problèmes.

Il reste donc trois options envisageables.

Option	À déguster de préférence lorsque	À surveiller :
Migrer dès maintenant	L'application est portable et vous disposez d'une capacité suffisante ce trimestre	Les glissements sont normaux, et l'exposition se poursuit pendant le glissement
Commandes de compensation uniquement	Entièrement isolé, aucune voie d'entrée non fiable	L'isolation se détériore insidieusement. Une simple modification du pare-feu suffit à la réactiver.
Assistance étendue assurée par le fournisseur	Vous devez corriger les vulnérabilités CVE tout en effectuant la migration selon votre propre calendrier	Précisez exactement quels paquets du système d'exploitation, environnements d'exécution et bibliothèques sont pris en charge

C'est cette troisième voie que propose le service « Endless Lifecycle Support » de TuxCare de TuxCare. Ce service fournit des correctifs de sécurité pour les environnements d’exécution, les bibliothèques, les frameworks et les applications qui ne bénéficient plus du support en amont, ainsi que pour les distributions Linux en fin de vie sur lesquelles ils reposent, via un système standard de gestion des paquets. Les systèmes couverts continuent de bénéficier de correctifs de sécurité, accompagnés d’une trace écrite correspondante, tandis que la migration s’effectue selon un calendrier que l’entreprise est réellement en mesure de financer.

Vérifier la mise en œuvre des mesures correctives et en apporter la preuve

Appliquer des correctifs sans vérification relève d'un système de croyances. Deux éléments rendent difficile de se fier à l'état des correctifs.

Le premier cas est celui d'un échec silencieux. Le paquet a bien été installé, mais le service n'a jamais redémarré, ou bien l'hôte a effectué une restauration, ou encore la mise à jour a été appliquée à l'image de base et non au conteneur en cours d'exécution. Le deuxième cas est celui d'un faux positif. Un scanner analyse une chaîne de version, ne détecte pas un correctif rétroporté et signale un CVE clôturé comme étant toujours ouvert.

Une vérification efficace permet d’obtenir plusieurs résultats concrets. Vous obtenez la confirmation, directement depuis le système en fonctionnement, que le code corrigé est bel et bien chargé, ainsi qu’un rapprochement entre le rapport de votre outil de correctifs et une analyse indépendante. Chaque hôte et chaque CVE dispose d’un enregistrement daté et exportable, prêt à être présenté à un auditeur. Et dans vos tickets, le statut « corrigé » est considéré comme confirmé, tandis que le statut « tenté » fait l’objet d’un suivi distinct.

La vérification tenant compte des rétroportages constitue le point faible sous Linux, car les scanners génériques interprètent souvent de manière erronée les paquets pour lesquels la distribution a rétroporté un correctif tout en conservant le numéro de version en amont. Quel que soit le scanner que vous utilisez, vérifiez ses résultats par rapport aux avis de sécurité de la distribution avant de consacrer un sprint à un CVE qui a déjà été corrigé.

Comment TuxCare comble ce fossé

C'est dans l'écart entre « correctif disponible » et « correctif appliqué » que se produisent la plupart des failles de sécurité. Equifax disposait du correctif depuis 67 jours avant que le vol de données ne commence. Dans le cas de Log4Shell, les attaquants étaient déjà à l'œuvre avant même que le premier correctif n'existe. Les équipes qui parviennent à combler cet écart sont généralement celles qui ont éliminé les causes structurelles de ces retards, à savoir les impasses liées à la fin de vie des produits (EOL), les paquets vulnérables qui ne cessent de se glisser dans les versions, et les redémarrages.

L'approche de TuxCare correspond directement à ces trois axes. Un support tout au long du cycle de vie couvre les environnements d’exécution, les frameworks, les applications et les systèmes d’exploitation dont les fournisseurs en amont se sont déjà désengagés. SecureChain remplace les registres publics par un registre géré par TuxCare, proposant des paquets vérifiés et mis à jour en continu pour JavaScript, Python, Java, Go et PHP, ce qui permet d’exclure les versions présentant des vulnérabilités connues des nouvelles versions. KernelCare gère l’application de correctifs au noyau sans redémarrage dans des environnements Linux mixtes. Choisissez la solution qui correspond le mieux à votre profil de risque.

Commencez par dresser un inventaire fiable. Décidez ensuite par quoi commencer.

FAQ