Vos CVE sont déjà exploitées avant que votre équipe les ait lues

En mai 2026, CVE-2026-48172 a été exploitée 24 heures après sa divulgation. CVE-2026-42897 l'a été sans qu'un seul patch existe. Ces cas ne sont pas des anomalies — ils sont la nouvelle norme. Le modèle de gestion des vulnérabilités que votre organisation applique encore — disclosure, CVSS, Patch Tuesday, 30 jours — est fondé sur des hypothèses qui ont cessé d'être vraies. Voici pourquoi, avec données et exemples, et ce que vous devez concrètement changer.

Le modèle classique repose sur des hypothèses obsolètes

Pendant des années, la gestion des vulnérabilités suivait une séquence logique et raisonnable. Un chercheur découvre une faille. Il la signale au vendor. Le vendor développe un patch — parfois en quelques semaines, parfois en quelques mois. Il publie le correctif, souvent lors d'un cycle mensuel comme le Patch Tuesday de Microsoft, premier mardi du mois. L'équipe IT déploie le patch en environnement de test, valide l'absence de régression, puis propage en production. Délai total admis pour les vulnérabilités critiques : 30 jours selon NIST SP 800-40 et les recommandations historiques de l'ANSSI et du CERT-FR.

Ce modèle assume implicitement que les attaquants ont besoin de temps : prendre connaissance de la faille, comprendre son fonctionnement, développer un exploit fiable, identifier les cibles vulnérables, et passer à l'action. Il suppose une fenêtre d'opportunité pour les défenseurs — quelques jours ou semaines entre la disclosure publique et la première exploitation réelle. Cette fenêtre a longtemps existé. Elle disparaît rapidement.

Les données publiées par Google Threat Intelligence Group pour 2025-2026 montrent que la médiane du délai entre divulgation publique et première exploitation confirmée est passée sous les 5 jours pour les CVE critiques touchant des logiciels d'entreprise largement déployés. Selon Mandiant, le "time to exploit" moyen sur les N-days populaires est désormais inférieur à 48 heures pour les failles affectant des équipements réseau exposés. Pour les zero-days comme CVE-2026-42897, le délai est par définition nul : exploitation et divulgation sont simultanées.

Des organisations comme l'ANSSI et le CERT-FR émettent d'ailleurs des recommandations d'application sous 48 heures pour les vulnérabilités critiques dans leurs bulletins d'alerte les plus urgents, ce qui reflète une prise de conscience réelle au niveau gouvernemental. Mais dans les faits, la majorité des organisations — PME, ETI, et même certaines grandes structures — appliquent encore des cycles mensuels voire trimestriels pour leurs patches de sécurité. L'écart entre la recommandation et la pratique terrain est béant, et les attaquants en tirent systématiquement profit.

Ce qui a fondamentalement changé, c'est l'industrialisation de l'exploitation. En 2016, développer un exploit fiable pour un CVE complexe prenait des semaines à un groupe organisé. En 2026, plusieurs facteurs structurels ont comprimé ce délai de manière radicale et probablement irréversible : la disponibilité publique de PoC sur GitHub en quelques heures après la divulgation, les marchés noirs d'exploits où des acteurs vendent des N-day fonctionnels en moins de 24 heures, l'automatisation des scans de masse via Shodan, Censys et ZoomEye permettant d'identifier les cibles vulnérables en minutes, et désormais l'assistance des modèles de langage dans le développement d'exploits. Le délai d'exploitation s'est effondré. Le modèle de défense n'a pas suivi.

Mai 2026 : un mois qui illustre parfaitement le problème

Les semaines de mai 2026 offrent une illustration presque pédagogique de ce phénomène. CVE-2026-48172, vulnérabilité CVSS 10.0 dans le plugin LiteSpeed cPanel, a été divulguée le 21 mai 2026. Dès le 22 mai — soit 24 heures plus tard — les premières campagnes opportunistes d'exploitation à grande échelle étaient documentées par Rescana, Field Effect et CyberSecurityNews. Des milliers de serveurs ont probablement été compromis avant même que leurs administrateurs aient eu connaissance de l'existence de la faille. Le patch existait, mais le délai entre sa disponibilité et son déploiement opérationnel a suffi aux attaquants pour agir massivement.

CVE-2026-42897, zero-day XSS dans Exchange Server OWA, a été divulgué le 14 mai 2026 par Microsoft — qui a simultanément confirmé l'exploitation active. Dans ce cas précis, il n'y avait pas de patch à déployer puisqu'aucun n'existait. Le modèle "attends le patch" ne fonctionnait tout simplement pas. Une organisation suivant un cycle mensuel de patch management aurait attendu la prochaine fenêtre de maintenance — alors que les attaquants agissaient le jour J avec un avantage structurel.

CVE-2026-20182, bypass d'authentification CVSS 10.0 sur Cisco SD-WAN Manager, a été exploité activement dans les 48 heures suivant sa divulgation publique du 14 mai 2026. La CISA l'a ajouté au catalogue KEV le même jour. Des organisations sans monitoring actif des alertes CISA ne l'ont probablement découvert que lors de leur prochain cycle de veille hebdomadaire — trop tard dans de nombreux cas.

Ghost CMS et CVE-2026-26980 : 700 sites compromis en moins de 48 heures après la divulgation, via une chaîne d'exploitation automatisée. Cette campagne démontre que l'exploitation n'est plus le domaine exclusif de groupes APT sophistiqués — des acteurs opportunistes avec des outils automatisés peuvent désormais cibler des milliers de systèmes vulnérables en quelques heures, exploitant des CVE publiés ce jour-là avant que la majorité des administrateurs ait même eu le temps de lire le bulletin.

Enfin, l'attaque de supply chain sur Laravel-Lang (22-23 mai 2026) illustre une surface d'attaque que le modèle classique de patch management ne couvre même pas. Il n'y avait pas de CVE à patcher : c'est l'infrastructure de confiance elle-même — GitHub tags, Packagist — qui était compromise. 700 versions malveillantes distribuées en 22 heures, un infostealer s'exécutant silencieusement dans des milliers d'applications PHP. La surface d'attaque s'étend bien au-delà des vulnérabilités CVE traditionnelles vers l'ensemble de la chaîne logicielle.

Ces exemples de mai 2026 ne sont pas des anomalies. Ils illustrent la norme. La vitesse d'exploitation s'est normalisée comme vecteur d'attaque standard, pas comme exception réservée aux acteurs les plus sophistiqués.

Le CVSS seul vous induit en erreur — voici pourquoi

Le CVSS (Common Vulnerability Scoring System) reste l'outil de référence pour la priorisation des vulnérabilités dans la plupart des organisations. Et c'est l'une des principales raisons pour lesquelles les programmes de patch management échouent à protéger correctement les organisations en 2026.

Le CVSS mesure la sévérité théorique d'une vulnérabilité selon des critères techniques : vecteur d'accès, complexité d'exploitation, privilèges requis, interaction utilisateur, impact sur la confidentialité, l'intégrité et la disponibilité. C'est un score de sévérité intrinsèque, calculé dans l'absolu, indépendamment du contexte réel d'exploitation. Il ne mesure pas la probabilité que la faille soit exploitée dans votre environnement, ni le fait qu'elle le soit déjà au moment où vous lisez la bulletin.

Le problème central est là : un CVE CVSS 7.2 activement exploité dans des campagnes ciblant votre secteur est infiniment plus dangereux qu'un CVE CVSS 9.8 pour lequel aucun PoC n'existe et aucune exploitation n'a été documentée. Prioriser uniquement selon le score CVSS revient à traiter le risque théorique plutôt que le risque réel. Et dans un contexte de ressources limitées — ce qui est la situation de la quasi-totalité des équipes IT —, cette erreur de priorisation a des conséquences directes sur le niveau de protection réel de l'organisation.

Selon une analyse publiée par FIRST en 2025, moins de 5% des CVE publiés chaque année font l'objet d'une exploitation confirmée. Sur les quelque 280 000 CVE enregistrés dans le NVD/NIST, seule une infime fraction a jamais été exploitée dans des attaques réelles. Parmi ces CVE effectivement exploités, la distribution des scores CVSS est hétérogène : on trouve des vulnérabilités "critiques" CVSS ≥ 9 jamais exploitées coexistant avec des CVE "moyens" CVSS 6-7 massivement utilisés dans des campagnes actives. Le CVSS seul ne prédit pas l'exploitation.

L'EPSS (Exploit Prediction Scoring System), développé et maintenu par FIRST depuis 2021, apporte une réponse beaucoup plus pertinente à la question "est-ce que cette faille sera exploitée ?". Il calcule une probabilité d'exploitation dans les 30 prochains jours pour chaque CVE, en s'appuyant sur des données réelles : publications de PoC, références dans des bulletins d'alerte, mentions sur des forums de sécurité, données de threat intelligence partagées. Un CVE avec un score EPSS élevé (supérieur à 0,5) mérite une attention immédiate quelle que soit sa note CVSS Base. Les principaux scanners de vulnérabilités du marché — Tenable Nessus/IO, Qualys VMDR, Rapid7 InsightVM — intègrent désormais l'EPSS comme critère de priorisation natif. Si votre équipe ne l'utilise pas encore, c'est une lacune à corriger en priorité.

La combinaison CVSS Base + score EPSS + statut dans le catalogue CISA KEV constitue aujourd'hui le cadre de priorisation le plus cohérent avec la réalité du risque opérationnel. Ces trois dimensions couvrent respectivement la sévérité intrinsèque, la probabilité d'exploitation imminente, et la confirmation d'exploitation active. Traiter ces trois indicateurs séparément n'est pas optimal — les croiser donne la vraie image du risque.

CISA KEV : l'indicateur que tout RSSI devrait surveiller en temps réel

Le catalogue Known Exploited Vulnerabilities (KEV) de la CISA, lancé en novembre 2021, est devenu en quatre ans l'un des outils de threat intelligence les plus opérationnels disponibles gratuitement pour les équipes de sécurité. Son principe est d'une clarté désarmante : la CISA y inscrit uniquement les CVE pour lesquels une exploitation active a été confirmée et vérifiée de manière indépendante. Pas des CVE théoriquement dangereux, pas des CVE avec un PoC public sur GitHub, pas des CVE jugés "critiques" selon leur score — des CVE effectivement utilisés dans des attaques réelles, contre des organisations réelles.

Fin mai 2026, le catalogue KEV contient environ 1 100 entrées sur les 280 000+ CVE référencés dans le NVD. Soit moins de 0,4% du total. C'est ce 0,4% que vous devez patcher en priorité absolue, avant tout le reste. Non pas parce qu'ils sont les plus sévères selon le CVSS — parfois ils ne le sont pas — mais parce qu'ils sont exploités maintenant, dans des attaques réelles, contre des organisations qui ressemblent probablement à la vôtre.

La règle opérationnelle que j'applique avec mes clients est la suivante : tout CVE ajouté au KEV doit être pris en charge sous 48 heures maximum, indépendamment du cycle de patch management habituel. C'est une dérogation au processus standard, traitée comme un incident de sécurité urgent avec escalade immédiate. Le délai standard de 30 jours s'applique aux CVE hors KEV avec score CVSS ≥ 8. Les CVE CVSS < 8 hors KEV avec EPSS faible peuvent suivre un cycle mensuel ou trimestriel selon la criticité du système concerné. Cette segmentation simple permet de concentrer l'énergie là où le risque est réel et immédiat, tout en ne négligeant pas le reste.

En mai 2026 uniquement, quatre CVE ont été ajoutés au KEV en l'espace de deux semaines : CVE-2026-20182 (Cisco SD-WAN, CVSS 10.0), CVE-2026-42897 (Exchange OWA, CVSS 8.1), CVE-2026-32202 (NTLM Windows, CVSS 7.5, exploité par APT28 depuis décembre 2025), et CVE-2026-48172 (LiteSpeed cPanel, CVSS 10.0). Quatre alertes critiques en 15 jours. Une organisation sans monitoring actif du KEV n'a pu réagir à temps sur aucune d'elles si elle attendait son prochain cycle de veille hebdomadaire.

Intégrer le KEV dans son processus opérationnel ne nécessite aucun budget supplémentaire. Le catalogue est disponible gratuitement au format JSON sur le site officiel de la CISA. La plupart des plateformes de gestion des vulnérabilités le consomment nativement. Pour les organisations sans plateforme dédiée, un script simple de surveillance du flux JSON KEV, couplé à l'inventaire des composants logiciels présents dans votre parc, peut envoyer des alertes automatiques via email ou Slack dès qu'un CVE affectant votre parc est ajouté. C'est du threat intelligence actionnable, gratuit, maintenu par une source gouvernementale crédible, et opérationnel en quelques heures de travail. Il n'y a aucune excuse valable pour ne pas l'utiliser.

L'IA entre les mains des attaquants : le changement de rythme qui vient

En mai 2026, le Google Threat Intelligence Group a publié un rapport documentant l'identification et le blocage d'une tentative d'exploitation à grande échelle dans laquelle l'acteur malveillant utilisait des modèles de langage pour automatiser la recherche de systèmes vulnérables et générer des exploits adaptés. Cette campagne spécifique a été contrée, mais elle illustre une tendance de fond qui va profondément changer les règles du jeu dans les années à venir.

Aujourd'hui, le développement d'un exploit fiable pour un CVE complexe nécessite encore des compétences spécialisées significatives. Un chercheur talentueux peut produire un PoC en quelques heures pour une vulnérabilité bien documentée dans un logiciel open-source. Mais pour des failles dans des systèmes propriétaires avec peu de documentation publique, ou des vulnérabilités nécessitant des primitives d'exploitation sophistiquées (kernel exploits, browser sandboxes, mécanismes de mitigations hardware), le travail peut prendre des jours ou des semaines même pour un expert. C'est cette barrière que l'IA commence à éroder.

Les LLMs apportent une assistance concrète à plusieurs étapes critiques du développement d'exploit : analyse automatisée du code de patch pour identifier les modifications critiques (patch diffing), génération de cas de test pour le fuzzing ciblé, aide à la compréhension des mécanismes d'exploitation dans des bases de code complexes, génération de shellcode ou de payloads adaptés à des contraintes de contexte spécifiques (ASLR, DEP, stack canaries). Chaque étape qui prenait plusieurs heures à un expert prend maintenant quelques minutes avec un assistant IA bien utilisé. Le délai global entre la publication d'un patch et la disponibilité d'un exploit fonctionnel s'en trouve mécaniquement comprimé.

La réduction de la barrière à l'entrée est tout aussi significative que l'accélération. Des acteurs moins qualifiés, qui n'auraient jamais pu développer un exploit complexe seuls, peuvent maintenant exploiter des CVE sophistiqués avec l'aide d'outils IA. Le bassin d'acteurs menaçants capables d'exploiter des vulnérabilités avancées s'élargit structurellement. Pour les défenseurs, cela signifie que les CVE étiquetés "complexité d'exploitation haute" selon le CVSS — et traditionnellement déprioritisés en conséquence — ne peuvent plus être traités avec le même niveau de sérénité. Un acteur assisté par IA peut réduire cette complexité de manière significative.

Les défenseurs ont bien sûr aussi accès à l'IA : détection comportementale assistée par LLMs, triage d'alertes automatisé, scanners de vulnérabilités avec scoring prédictif alimenté par machine learning, corrélation d'indicateurs de compromission à grande échelle. Ces outils existent et s'améliorent rapidement. Mais la vraie question est de savoir qui adopte ces capacités plus vite : les attaquants, qui n'ont pas de processus d'achat, de RSSI, de comité de validation ou d'audit de sécurité préalable à l'adoption d'un nouvel outil, ou les défenseurs, contraints par leurs budgets, leurs processus organisationnels et leurs obligations réglementaires ? Pour l'instant, la tendance n'est pas en faveur des défenseurs. Mais l'écart se réduit pour ceux qui investissent vraiment dans ce domaine.

Ce que vous devez concrètement changer dans votre programme de patch management

La bonne nouvelle est que les ajustements nécessaires ne requièrent pas une révolution budgétaire. Ils nécessitent une révision des priorités et des processus, pas nécessairement de nouveaux outils coûteux. Voici les actions à mener, par ordre de priorité et d'impact.

1. Restructurez vos SLA de patch management autour de trois niveaux. Premier niveau : tout CVE présent dans le CISA KEV → remédiation sous 48 heures, traité comme un incident de sécurité avec escalade immédiate hors cycle normal. Deuxième niveau : CVE CVSS ≥ 8 ou score EPSS ≥ 0,5 → remédiation sous 7 jours. Troisième niveau : CVE CVSS < 8 hors KEV avec EPSS faible → cycle mensuel ou trimestriel selon la criticité du système concerné. Cette segmentation simple permet de réduire drastiquement le bruit et de concentrer les ressources là où le risque est réel et immédiat, sans abandonner le reste.

2. Automatisez la surveillance du CISA KEV. Un script de monitoring du flux JSON KEV, couplé à votre inventaire de composants logiciels (CMDB ou SBOM), peut envoyer des alertes automatiques dès qu'un CVE affectant votre parc y est ajouté. Cette mise en place prend quelques heures et élimine la dépendance à une veille manuelle hebdomadaire. Le coût de développement et de maintenance est marginal ; la valeur opérationnelle est immédiate.

3. Implémentez un SBOM (Software Bill of Materials). L'attaque Laravel-Lang a démontré une nouvelle fois que sans inventaire précis des composants logiciels utilisés, il est impossible de savoir en quelques minutes si vous êtes exposé à une attaque de supply chain. Un SBOM maintenu à jour est aujourd'hui un prérequis à une réponse rapide. Des outils comme Syft, Grype ou Dependency-Track permettent de le construire et de le maintenir sans budget significatif, en s'intégrant nativement dans les pipelines CI/CD.

4. Adoptez une politique d'application automatique des patches pour les systèmes à faible risque opérationnel. Serveurs web statiques, instances de test, équipements réseau non critiques, environnements de développement — pour ces systèmes, les patches de sécurité critiques peuvent être appliqués automatiquement dès disponibilité. Réservez les fenêtres de maintenance avec validation manuelle aux systèmes où la disponibilité est critique : bases de données de production, systèmes industriels, environnements hautement contrôlés. L'automatisation du patch sur les systèmes non critiques supprime le délai d'exposition sans créer de risque opérationnel supplémentaire.

5. Réduisez proactivement votre surface d'attaque. Au-delà des patches, la réduction de la surface d'attaque est la stratégie la plus efficace à long terme contre cette classe de menaces. Exchange OWA exposé directement sur Internet alors qu'un VPN est disponible ? Restreignez l'accès. Ports de gestion accessibles publiquement ? Fermez-les. Plugins inutilisés activés — comme le plugin LiteSpeed User-End pour des utilisateurs sans serveur Redis — ? Désactivez-les. Chaque composant supprimé ou restreint est une CVE future qui ne vous concernera pas. La sécurité par la réduction de surface n'a pas de coût de patch management associé.

6. Planifiez votre réponse à l'incident avant qu'il arrive. La vitesse d'exploitation actuelle implique qu'une organisation sera parfois compromise avant d'avoir pu patcher — c'est une réalité statistique, pas un aveu de faiblesse. Le modèle de sécurité "périmétrique + patches dans les temps" ne suffit plus. La capacité à détecter rapidement une compromission (monitoring comportemental, NDR/EDR bien configuré, détection d'anomalies réseau) et à y répondre efficacement (procédures d'incident response testées et documentées, sauvegardes intègres, capacité de reconstruction vérifiée) est aussi importante que la prévention. Planifier la réponse à l'incident avant qu'il n'arrive, c'est accepter lucidement la réalité du risque résiduel et s'y préparer.

Conclusion

Le modèle classique de gestion des vulnérabilités était adapté à une époque où les attaquants avaient besoin de temps. En 2026, CVE-2026-48172 exploitée en 24h, CVE-2026-42897 exploitée sans patch disponible, Laravel-Lang compromis en 22 heures de fenêtre d'exposition : ces événements de mai 2026 ne sont pas des cas extrêmes. Ils sont la nouvelle norme vers laquelle convergent structurellement les capacités offensives.

Adapter son programme de patch management n'est pas une option réservée aux grandes organisations avec des équipes de sécurité étoffées. C'est une nécessité opérationnelle pour toute organisation qui ne souhaite pas subir une compromission évitable. Le KEV, l'EPSS, la réduction de surface d'attaque, le SBOM, l'automatisation des patches sur les systèmes non critiques : ces outils et méthodes sont accessibles, souvent gratuits, et leur mise en œuvre est à portée d'une équipe IT même modeste. La question n'est pas de savoir si vous pouvez vous le permettre. C'est de savoir si vous pouvez vous permettre de ne pas le faire.