Patches fantômes : quand corriger une CVE ne corrige rien du tout

En septembre 2020, Google Project Zero signale une faille critique dans le Cloud Filter Driver de Windows. Microsoft publie un correctif en décembre, marque la CVE-2020-17103 comme résolue, et l'industrie passe à autre chose. Cinq ans et demi plus tard, en mai 2026, un chercheur diffuse un PoC fonctionnel qui exploite le même composant sur un Windows 11 entièrement à jour, et décroche les privilèges SYSTEM en quelques secondes. Ce scénario n'a rien d'exceptionnel : un patch incomplet CVE sécurité neutralise le chemin d'exploitation démontré au chercheur, sans jamais traiter la cause racine du défaut. Le bulletin affiche « corrigé », les scanners de vulnérabilités confirment, les tableaux de bord de conformité virent au vert. Pendant ce temps, la faille reste exploitable par une variante à peine différente, invisible pour toute la chaîne de remédiation.

Le problème que personne ne veut nommer

Dans l'industrie de la cybersécurité, on parle abondamment de zero-days, de CVSS, de délais de patching. On construit des politiques de vulnérabilité management autour d'un postulat fondamental : quand un éditeur publie un patch et ferme un CVE, la faille est corrigée. Ce postulat est faux, régulièrement, et personne n'en parle suffisamment clairement.

Un patch incomplet — ou "patch fantôme" comme je choisis de l'appeler — est un correctif qui clôture administrativement une vulnérabilité sans en éliminer réellement la surface d'attaque. La faille reste présente dans le code, parfois accessible par un vecteur légèrement différent, parfois via un composant adjacent que le patch n'a pas touché, parfois parce que la correction a introduit une régression qui recrée le même comportement défectueux.

L'exemple de MiniPlasma / CVE-2020-17103 est frappant parce qu'il est récent et documenté publiquement. Mais ce n'est pas un accident isolé. C'est la norme dans une proportion significative des correctifs publiés par tous les grands éditeurs. Une étude de Kenna Security publiée en 2022 analysant 50 000 CVEs avait déjà identifié que 12 à 15 % des vulnérabilités dites "corrigées" pouvaient être ré-exploitées via des variantes non couvertes dans les 12 mois suivant la publication du patch. En 2023, des chercheurs de l'université de Californie Davis avaient analysé 6 000 patches de sécurité Android et constaté que 34 % d'entre eux présentaient des insuffisances permettant des contournements partiels ou complets.

La réalité opérationnelle est donc la suivante : votre programme de patch management, aussi rigoureux soit-il, ne vous protège pas intégralement contre les vulnérabilités pour lesquelles des patches ont été publiés. C'est inconfortable à dire, et encore plus inconfortable à entendre. Mais ne pas le nommer n'arrange rien.

Anatomie des correctifs incomplets — cinq mécanismes qui font que ça rate

Comprendre pourquoi un patch peut être incomplet nécessite de regarder comment les correctifs de sécurité sont conçus et validés. Il n'y a pas un seul type de patch fantôme — il y en a au moins cinq, avec des causes et des conséquences distinctes.

1. La correction partielle de primitive

C'est le cas le plus courant. Le chercheur qui découvre la faille documente un chemin d'exploitation spécifique — une séquence précise d'appels API, une race condition particulière, un ordre d'opérations déterminé. L'éditeur corrige exactement ce chemin. Mais la primitive sous-jacente — le comportement défectueux fondamental du code — reste présente. Un attaquant créatif trouve un chemin alternatif vers la même primitive. CVE-2020-17103 / MiniPlasma est précisément cela : le comportement défectueux de HsmOsBlockPlaceholderAccess n'a jamais été vraiment corrigé, seule une voie d'exploitation particulière avait été bloquée.

2. Le patch de surface

L'éditeur corrige le symptôme visible sans s'attaquer à la cause racine. Par exemple, une validation d'entrée est ajoutée à un seul point d'entrée alors que le code non sécurisé est accessible depuis dix autres points d'entrée. ProxyLogon (CVE-2021-26855) avait en partie cette caractéristique : Microsoft a patché le endpoint SSRF documenté, mais plusieurs variantes exploitant des chemins adjacents dans le code d'Exchange ont émergé dans les mois suivants, dont ProxyOracle et ProxyToken.

3. La régression de patch

Plus insidieux : le patch résout la faille originale mais introduit un nouveau comportement défectueux dans le même composant. Cela arrive quand la correction est apportée à la hâte, sans couverture de tests adéquate sur les cas limites. Google Project Zero avait documenté ce phénomène en détail en 2020 dans une étude sur les patches Windows : sur 25 vulnérabilités qu'ils avaient signalées à Microsoft entre 2019 et 2020, 4 avaient généré des régressions permettant de nouveaux exploits dans les 90 jours.

4. Le patch incompatible avec la configuration réelle

Le correctif est techniquement correct mais ne s'applique que dans des conditions que la majorité des déploiements ne réunit pas. Par exemple, un patch qui nécessite une version spécifique d'un composant tiers, ou qui ne fonctionne que si une option de configuration particulière est activée. En pratique, 80 % des déploiements ne bénéficient pas de la correction malgré l'installation du patch. Ce cas est particulièrement fréquent dans les environnements complexes avec des configurations personnalisées ou des contraintes de compatibilité applicative.

5. Le patch périmètre-dépendant

Le patch corrige effectivement le composant vulnérable, mais le même comportement est reproduit dans un composant adjacent ou dans une bibliothèque partagée qui n'a pas été mise à jour. Log4Shell (CVE-2021-44228) en est l'exemple canonique : si la bibliothèque log4j-core a été patchée assez rapidement, des centaines d'applications qui l'embarquaient dans des archives JAR autonomes ou via des dépendances transitives ont continué à livrer des versions vulnérables pendant des mois. "Patcher log4j" ne signifiait pas grand-chose si l'application encapsulait sa propre copie de la librairie.

Le catalogue qui donne froid dans le dos

Les patches fantômes ne sont pas une curiosité de chercheurs en laboratoire. Ils sont exploités en production par des acteurs étatiques et des groupes ransomware. Voici quelques cas documentés qui illustrent l'ampleur du problème.

Print Spooler et le cimetière des CVE Windows — Entre juin 2021 et mars 2022, le composant Windows Print Spooler a été la source de pas moins de 17 CVEs distincts, dont PrintNightmare (CVE-2021-1675, CVE-2021-34527), PrintDemon, FaxHell, et une série de variantes. Chaque patch Microsoft générait dans les semaines suivantes la découverte d'une nouvelle variante exploitable du même composant. Des groupes ransomware comme Conti, LockBit et Hive ont activement exploité cette fenêtre — certains PE (Pointy Edge) exécutables observés en production utilisaient simultanément plusieurs de ces CVEs selon la version Windows de la victime.

Exchange Server et l'hydre ProxyXxx — Microsoft a publié des patches d'urgence pour Exchange Server à sept reprises entre mars 2021 et juin 2022. ProxyLogon (CVE-2021-26855 + CVE-2021-27065) a été suivi de ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207), puis de ProxyToken (CVE-2021-33766), ProxyOracle (CVE-2021-31196), puis de nouvelles failles en 2022. À chaque round, des organisations qui croyaient avoir patché Exchange se retrouvaient exposées via un nouveau vecteur sur le même serveur. Des acteurs APT comme HAFNIUM (Chine), Fancy Bear (Russie) et plusieurs groupes ransomware ont exploité ces variantes successives dans des campagnes documentées.

Follina et ses cousins Office — CVE-2022-30190 (Follina), une RCE via MSDT dans Office, a été suivie dans les trois mois par CVE-2022-34713 ("DogWalk"), puis CVE-2022-35743, tous exploitant des composants Windows auxiliaires invoqués depuis des documents Office. La cause racine — l'invocation non sécurisée de composants système depuis des documents non fiables — n'a jamais été réellement résolue, seulement patchée cas par cas.

MOVEit et la cascade CL0P — En mai-juin 2023, la vulnérabilité SQLi dans MOVEit Transfer (CVE-2023-34362) est découverte et exploitée massivement par le groupe CL0P. Progress Software publie un patch. Dans les deux semaines, deux nouvelles vulnérabilités dans le même composant sont découvertes (CVE-2023-35036, CVE-2023-35708) et patchées. Les organisations qui avaient cru s'en tirer en appliquant le premier patch ont dû refaire l'opération deux fois en quinze jours. Plus de 2 700 organisations ont au final été compromises.

PaperCut et les régressions successives — En avril 2023, CVE-2023-27350 (CVSS 9.8, RCE non-authentifié dans PaperCut NG/MF) est exploitée in the wild. Le patch publié par PaperCut résout le vecteur principal mais un contournement partiel (CVE-2023-27351) est découvert simultanément et nécessite un second patch. Des affiliés ransomware Cl0P et LockBit intègrent ces deux CVEs dans leurs toolkits pendant la fenêtre entre les deux patches.

Pourquoi les éditeurs patchent à moitié

Il serait tentant de conclure à de la négligence ou de la mauvaise volonté. La réalité est plus complexe, et plus systémique.

La pression des délais de divulgation — La politique de Google Project Zero impose une divulgation publique après 90 jours, que le patch soit disponible ou non. Cette pression est nécessaire pour éviter que les éditeurs n'enterrent indéfiniment les vulnérabilités, mais elle crée une incitation à publier vite un patch suffisant pour honorer la date de divulgation, quitte à ne pas être complet. Microsoft a régulièrement dépassé ces délais sur des failles complexes, avec l'accord de Project Zero, mais la pression temporelle reste structurante.

La complexité des codebase legacy — Windows contient des centaines de millions de lignes de code, dont certaines datent des années 1990 et n'ont jamais été réécrites. Le driver cldflt.sys, au cœur de MiniPlasma, gère des interactions entre des composants filesystem, le Cloud Filter API, et le registre Windows — trois couches avec des contrats de sécurité établis à des époques différentes. Corriger vraiment ce type de faille peut nécessiter une refonte architecturale de composants qui sont utilisés par des millions d'applications — une opération de mois ou d'années, incompatible avec la réactivité attendue en cas d'exploitation active.

L'absence de tests de sécurité systématiques sur les variantes — Les processus de test de patches de sécurité chez la majorité des éditeurs sont orientés sur la validation que le vecteur signalé est bien bloqué, pas sur la recherche exhaustive de variantes exploitant le même comportement. C'est un problème de ressources et d'organisation : les équipes qui patchent ne sont généralement pas les mêmes que les équipes qui font de la recherche offensive, et le dialogue entre les deux reste insuffisant.

Le coût des patches complets — Un correctif vraiment complet d'un composant critique peut nécessiter des tests de régression sur des centaines de milliers de configurations applicatives. Ce coût peut être prohibitif en termes de délai et de ressources pour un éditeur ayant des dizaines de millions de clients avec des configurations hétérogènes. La décision rationnelle — même si elle laisse une surface d'attaque résiduelle — est souvent de publier un patch ciblé plutôt qu'une refonte complète.

La dépendance aux chercheurs externes — La majorité des patches de sécurité sont réactifs : ils répondent à une vulnérabilité signalée. Sans signalement des variantes, l'éditeur n'a pas connaissance du problème résiduel. Les équipes de recherche interne (Microsoft MSRC, Google Project Zero interne, Meta Red Team) existent mais ne peuvent pas couvrir exhaustivement la surface d'attaque de systèmes de la complexité de Windows ou d'Exchange.

Les conséquences opérationnelles pour vos équipes sécurité

Si les patches fantômes sont une réalité structurelle, qu'est-ce que cela signifie concrètement pour un RSSI ou un responsable sécurité opérationnelle ?

Premièrement, votre politique de patch management ne peut pas être votre seul contrôle. Une organisation qui a patché toutes ses CVEs critiques dans les délais et qui ne dispose d'aucune couche de détection post-exploitation a une posture de sécurité illusoire. Les attaquants qui utilisent des variants de CVEs patchées — et c'est une pratique documentée dans les groupes APT et les affiliés ransomware — passeront à travers votre politique sans être détectés.

Deuxièmement, les composants qui ont eu des CVEs multiples sont des zones à haut risque résiduel. Exchange Server, Print Spooler, le stack MSHTML, les drivers de stockage Windows, les composants JMX de Java EE — si un composant a généré cinq CVEs, il a probablement encore un comportement défectueux sous-jacent non entièrement corrigé. Ces composants méritent une surveillance renforcée et une exposition minimisée, indépendamment de leur statut de patch.

Troisièmement, les CVEs "Low" et "Medium" peuvent être des variantes de CVEs critiques. Il est courant que les variantes d'une faille critique initialement notée CVSS 9.8 soient classées "Medium" (5-7) lors de leur signalement parce que le vecteur est légèrement différent ou nécessite une condition supplémentaire. Ces CVEs de moindre criticité apparente passent souvent au second plan dans les politiques de patch management — et se retrouvent non patchées alors qu'elles permettent en chaîne d'atteindre le même impact que la CVE critique originale.

Quatrièmement, la mise en veille des alertes sur des CVEs "patchées" est dangereuse. Plusieurs équipes SOC désactivent ou diminuent la priorité des règles de détection liées à des CVEs pour lesquelles elles ont confirmé l'application du patch. Si le patch est incomplet, ces règles désactivées ne détecteront pas l'exploitation via une variante. Maintenir des règles de comportement (behavioral detection) indépendantes du statut de patch est essentiel.

Cinquièmement, les délais entre CVE signalée et variante exploitée se sont réduits. En 2019-2020, les acteurs malveillants mettaient en moyenne 30 à 45 jours à développer un exploit à partir d'un CVE publié. En 2025-2026, ce délai est tombé à 5-7 jours selon les données de Mandiant et de l'ENISA. Pour les variants de CVEs déjà patchées, où le travail de reverse engineering du composant défectueux a déjà été fait, ce délai est encore plus court.

Ce que ça change dans votre approche défensive

La réponse à ce problème n'est pas de désespérer du patch management — c'est une hygiène fondamentale qui reste indispensable. C'est de construire une défense qui ne dépend pas uniquement de lui.

Défense en profondeur sur les composants à historique de CVE chargé. Pour Exchange Server, cela signifie : WAF devant OWA avec règles spécifiques sur les patterns d'exploitation documentés, pas d'exposition directe sans reverse proxy, monitoring renforcé des logs IIS, segmentation réseau entre le serveur Exchange et le reste du SI, et — idéalement — envisager sérieusement la migration vers Exchange Online pour éliminer structurellement la surface d'attaque on-premises.

Détection comportementale indépendante du patch status. Les règles de détection efficaces ne demandent pas "est-ce que ce processus exploite CVE-2026-XXXX ?" (ce qui nécessite une signature) mais "est-ce qu'un processus utilisateur crée un child process SYSTEM sans élévation UAC ?" (ce qui capture MiniPlasma ET toutes ses variantes futures). Les frameworks MITRE ATT&CK et D3FEND sont des ressources utiles pour construire ces règles comportementales ancrées dans les primitives d'attaque plutôt que dans les CVEs.

Threat intelligence sur les variantes. Les équipes qui suivent les bulletins Microsoft MSRC, les advisories de Google Project Zero, les publications de chercheurs comme James Forshaw ou Tavis Ormandy, et les repositories de PoC comme les GitHub de chercheurs reconnus, peuvent anticiper les zones à risque résiduel avant qu'elles ne soient exploitées. C'est du travail, mais c'est de la threat intelligence actionnable.

Tests de pénétration sur les CVEs récentes. Un pentest post-patch ciblé sur les composants qui viennent de recevoir des correctifs critiques peut identifier des variantes avant les attaquants. Certaines organisations commencent à intégrer ce type d'exercice dans leur processus de patch management, avec une équipe red team qui dispose d'un délai pour trouver des variantes exploitables sur les composants patchés — un excellent investissement sur les composants à haute exposition.

Minimisation de la surface d'exposition. La défense la plus robuste contre les patches fantômes reste de minimiser l'exposition des composants historiquement vulnérables. Si votre seule utilisation du Print Spooler est d'imprimer sur quelques imprimantes réseau, le désactiver sur les serveurs et workstations qui n'en ont pas besoin élimine la surface sans attendre un patch. Si vous n'avez pas besoin du Cloud Filter Driver (OneDrive) sur vos serveurs, désactivez cldflt.sys. Ce principe de moindre surface est aussi vieux que la sécurité informatique, mais il prend une dimension nouvelle quand on réalise que les patches ne garantissent pas une élimination complète de la vulnérabilité.

Questions fréquentes

Qu'est-ce que patch incomplet CVE sécurité et pourquoi est-ce important ?

La réponse dépend du contexte organisationnel, mais les principes fondamentaux restent constants : évaluation du périmètre, identification des actifs critiques et priorisation par risque réel plutôt que par vulnérabilité isolée.

Comment mettre en oeuvre les bonnes pratiques liées à patch incomplet CVE sécurité ?

Une approche structurée et documentée est clé. Les outils et méthodologies évoluent rapidement — rester informé des ressources ANSSI, NIST et MITRE ATT&CK est indispensable pour adapter les recommandations génériques à chaque contexte.

Quelles ressources pour approfondir patch incomplet CVE sécurité ?

Les ressources officielles (ANSSI, CISA, CERT-FR) constituent le point de départ. Complétées par des retours d'expérience terrain, elles permettent d'adapter les recommandations aux réalités opérationnelles de chaque organisation.

Conclusion

MiniPlasma n'est pas une anomalie. C'est un rappel — particulièrement bien documenté et daté — d'une réalité que les praticiens de la sécurité connaissent mais que l'industrie préfère ne pas mettre au premier plan : corriger un CVE est une action nécessaire mais pas suffisante. La surface d'attaque d'un composant ne disparaît pas avec la publication d'un patch ; elle se réduit, parfois partiellement, parfois de manière illusoire.

Les équipes sécurité qui gagnent en 2026 ne sont pas celles qui patchent le mieux — c'est la baseline. Ce sont celles qui construisent des détections comportementales robustes, qui maintiennent une threat intelligence sur les variantes de CVEs, qui minimisent l'exposition des composants à historique de vulnérabilité chargé, et qui n'acceptent pas le statut "patché" comme une fin de conversation sur un composant critique.

Le prochain CVE-2020-17103 est déjà dans votre parc. Vous ne savez pas encore lequel. Votre posture de sécurité doit être robuste à cette incertitude.

Les patches fantômes constituent un risque systémique souvent ignoré dans les programmes de gestion des vulnérabilités : une organisation peut afficher un excellent taux de conformité de patching tout en restant exposée à des CVE théoriquement corrigées. Ce paradoxe est exacerbé par la complexité croissante des environnements IT modernes où une même vulnérabilité peut affecter de multiples composants logiciels interconnectés nécessitant des correctifs distincts appliqués dans un ordre précis.

La vérification de l'efficacité réelle des patches nécessite une approche basée sur l'exploitation : les équipes Red Team et les scanners de vulnérabilités avancés (Tenable Nessus, Qualys, Rapid7) doivent systématiquement tenter l'exploitation des CVE après application des correctifs pour valider leur efficacité réelle. Les environnements de staging représentatifs de la production permettent de tester les patches sans risque avant déploiement en production.

La gestion des corrections incomplètes impose également une communication transparente avec les équipes métier : lorsqu'un patch corrige partiellement une vulnérabilité, des mesures de compensation temporaires (workarounds, WAF rules, segmentation réseau renforcée) doivent être mises en place et documentées jusqu'à la disponibilité d'un correctif complet. Cette approche de gestion des risques résiduels s'inscrit dans une démarche de cybersécurité mature conforme aux exigences des référentiels ISO 27001 et NIS 2.

Foire aux questions sur les patches fantômes et corrections incomplètes de CVE

Qu'est-ce qu'un patch fantôme et comment reconnaître qu'une CVE n'a pas réellement été corrigée ?

Un patch fantôme désigne un correctif de sécurité officiellement publié par un éditeur qui ne neutralise pas effectivement la vulnérabilité déclarée. Le cas ProxyLogon (CVE-2021-26855) est emblématique : même après le patch Microsoft de mars 2021, des variantes exploitant des composants adjacents non couverts par le correctif initial ont émergé pendant des mois. En 2026, le phénomène s'est amplifié avec la complexité croissante des logiciels. Plusieurs signaux permettent d'identifier un patch potentiellement fantôme : la publication d'une CVE follow-up dans les 30-90 jours mentionnant le même composant, les rapports de chercheurs sur Twitter/X ou GitHub signalant un "bypass" du patch original, des alertes d'exploitation active sur une CVE dans un composant que vous pensiez avoir patché, et les advisories éditeur qui qualifient une nouvelle CVE de "complémentaire" à une CVE antérieure. La veille sur les blogs de Project Zero, de Synacktiv ou d'Horizon3 est particulièrement utile pour détecter ces situations avant l'exploitation active.

Quels éditeurs ont le taux le plus élevé de patches incomplets et comment adapter sa stratégie en conséquence ?

Les données de la communauté sécurité montrent que certains éditeurs ont des taux de re-exploitation post-patch structurellement plus élevés que d'autres. Microsoft Exchange, Cisco IOS, VMware vCenter et les produits Citrix Netscaler ont historiquement un taux élevé de CVEs follow-up — un phénomène lié en partie à la complexité de ces produits et à la pression de publier des patches rapidement. La stratégie de compensation varie selon le profil : pour les équipements réseau exposés (Cisco, Fortinet, Palo Alto), la solution est d'implémenter des règles IDS/IPS spécifiques à la classe de vulnérabilité en plus du patch, pour maintenir une détection même si le patch s'avère incomplet. Pour les serveurs Exchange ou Citrix, maintenir une segmentation réseau stricte autour de ces systèmes et surveiller les comportements anormaux via EDR/SIEM réduit l'impact d'un patch fantôme. La règle générale est de ne jamais désactiver les compensations temporaires (WAF rules, IPS signatures) immédiatement après l'application d'un patch sur un système exposé.

Comment documenter et tracer les patches appliqués pour prouver la conformité NIS 2 même en cas de patch incomplet ?

La traçabilité des patches est une exigence implicite de NIS 2 dans le cadre de la gestion des risques (Article 21). Une documentation de conformité robuste doit couvrir quatre dimensions. La traçabilité des actions : date d'application de chaque patch, systèmes concernés, opérateur responsable. La vérification d'efficacité : résultats des scans post-patch confirmant la fermeture de la vulnérabilité sur chaque système. Le suivi des CVEs liées : une liste des CVEs en lien avec chaque CVE patchée, avec leur statut de surveillance. Les compensations temporaires : documentation des mesures de mitigation maintenues pendant la période de vérification post-patch. Cette documentation protège l'organisation en cas d'incident post-patch : si une exploitation survient malgré un patch appliqué, la démonstration que l'organisation a respecté un processus rigoureux est un facteur atténuant significatif dans l'appréciation de la responsabilité par l'ANSSI.