Patch incomplet : la nouvelle dette technique de la cyberdéfense

CVE-2026-32202 ré-exploite un vecteur que Microsoft pensait avoir colmaté il y a six mois. Ce n'est pas un raté isolé. C'est devenu la norme : les éditeurs livrent des patchs qui traitent un symptôme, jamais la racine. Et nous, défenseurs, on découvre la facture en lisant les bulletins CISA — toujours en retard d'une exploitation.

Six mois entre deux patchs pour la même classe de bug

Reprenons la chronologie. Octobre 2025 : APT28 exploite CVE-2026-21510 et CVE-2026-21513, une chaîne de fichiers .lnk piégés contournant Mark-of-the-Web et SmartScreen pour exécuter du code à distance. Microsoft publie un patch en février 2026. Six mois plus tard, le 14 avril 2026, nouveau patch — CVE-2026-32202 — pour fermer la coercition NTLM que la première rustine avait laissée ouverte. Et la CISA confirme l'exploitation active fin avril.

Question légitime : qu'est-ce qui s'est passé entre février et avril ? Réponse : APT28 a continué tranquillement à voler des hashes NTLM via le même vecteur, parce que Microsoft avait fermé l'exécution de code mais pas la connexion SMB sortante déclenchée par le simple rendu d'icône. Le patch initial a fait ce qu'il était censé faire dans le ticket : empêcher le RCE. Sauf que la vulnérabilité n'était pas le RCE. La vulnérabilité, c'était la chaîne complète depuis l'ouverture du dossier jusqu'à la compromission du compte. Microsoft a réparé un maillon. Le reste est resté exploitable.

Cette logique du correctif minimal n'est pas propre à Microsoft. Cisco a publié trois révisions de l'avis CVE-2024-20419 (Smart Software Manager) en 2025 parce que chaque correctif ouvrait une variante. Ivanti a battu un record peu enviable avec EPMM : six patchs successifs entre janvier et avril 2026 pour CVE-2026-1281, chaque correctif laissant un bypass exploitable en quelques jours. VMware n'est pas mieux loti — Broadcom a hérité de patchs ESXi qui se contournent par paramètre VMX modifié.

Pourquoi cette dérive ? Trois raisons structurelles

Première raison : les éditeurs raisonnent en CVE, pas en surface d'attaque. Quand un chercheur soumet un rapport, il décrit un PoC précis. L'ingénieur produit colmate ce PoC. Personne ne demande « et si on déplace l'origine de la coercition à un autre endroit du même composant ? ». Le triage interne a un objectif : réduire le score CVSS de la CVE déposée. Pas penser comme un attaquant.

Deuxième raison : l'industrialisation des releases. Microsoft a engagé l'industrie dans un cycle Patch Tuesday mensuel qui crée une pression sur les délais. Chaque mois, 100 à 200 vulnérabilités à corriger, à tester en régression, à packager. Quand le calendrier serre, on prend le patch minimal qui ferme le PoC, on l'envoie en QA, on livre. Le patch architectural — celui qui repenserait la confiance accordée au rendu d'icône .lnk dans un dossier non vérifié — demanderait six mois de chantier transverse. Personne ne l'autorise.

Troisième raison : les attaquants étatiques achètent désormais des chaînes complètes, pas des CVE. Quand APT28 paie 1 à 3 millions à un courtier pour un exploit Windows, ce qu'il achète c'est un kit avec trois variantes du même bug et un calendrier de rotation. Patch sur le PoC public ? Variante #2 prend le relais. Patch sur la variante #2 ? Variante #3. Microsoft court derrière une cible mobile, le défenseur court derrière Microsoft, et l'attaquant garde toujours deux longueurs d'avance.

Ce que ça change pour les RSSI

Premier effet : on ne peut plus faire confiance à la matrice CVSS comme indicateur unique de priorisation. CVE-2026-32202 a un score officiel de 4.3. Sur le papier, vous la classez en sprint 3 du trimestre. Sauf qu'elle est exploitée par un APT depuis deux semaines avec un impact réel sur Active Directory. Le CVSS mesure la complexité technique, pas la pression d'exploitation. Il faut désormais croiser systématiquement avec le KEV de la CISA, l'EPSS (Exploit Prediction Scoring System) et le threat intel sectoriel.

Deuxième effet : la durée de vie d'un patch n'est plus l'année, c'est le mois. Si vous avez patché en février, vous n'êtes pas protégé contre une variante d'avril. Le patch management redevient une activité hebdomadaire active, pas un processus annuel de conformité. Les organisations qui appliquent leurs patchs au trimestre — et il y en a encore beaucoup — naviguent sans bouclier.

Troisième effet, le plus inconfortable : le patch ne suffit plus. Sur CVE-2026-32202, appliquer le KB d'avril ferme un vecteur. Ça ne ferme pas la coercition NTLM en général (PetitPotam, PrinterBug, DFSCoerce restent triviaux). La défense en profondeur n'est plus une bonne pratique optionnelle, c'est la dernière ligne avant la compromission. Bloquer le SMB sortant en bordure, désactiver NTLM sortant par GPO, activer LDAP signing et channel binding : ces contrôles font le travail que les patchs n'arrivent plus à faire seuls.

Le cas particulier de la documentation des patchs

Microsoft mérite une critique spécifique sur la communication. CVE-2026-32202 a été publiée le 14 avril sans la mention « Exploited: Yes » et sans aucune indication qu'il s'agissait d'un correctif incomplet du précédent zéro-day APT28. Conséquence : les équipes sécurité qui priorisent en lecture rapide du bulletin Patch Tuesday ont rangé cette CVE dans la pile des « important non-critique ». Deux semaines de retard sur le déploiement, deux semaines pendant lesquelles APT28 a continué d'exploiter en toute tranquillité.

Cette opacité n'est pas un détail. Quand un éditeur publie un correctif partiel d'une chaîne d'exploitation déjà en circulation, il a une obligation morale et opérationnelle de le signaler. Marquer la CVE comme « partial fix » ou « follow-up to CVE-XXXX », documenter les vecteurs résiduels, indiquer la priorité réelle. Microsoft ne le fait pas. Cisco et VMware non plus. Le résultat est mécaniquement la même chose : les défenseurs perdent la course.

Et l'open source dans tout ça ?

L'open source n'est pas exempt mais il a au moins l'avantage de la transparence. Quand le noyau Linux corrige une race condition kernel, le commit est visible, le diff est lisible, les chercheurs peuvent immédiatement vérifier si le fix couvre toutes les variantes ou s'il reste des chemins d'exploitation. Pour Microsoft, on lit un KB qui dit « addresses a vulnerability in Windows Shell » et puis débrouille-toi.

Cette asymétrie d'information explique pourquoi les chercheurs offensifs (Akamai, Project Zero, Trellix) découvrent les correctifs incomplets de Microsoft en quelques jours alors que la même équipe interne Microsoft les a manqués pendant six mois. Le Bug Variant Hunting est une discipline industrialisée chez les chercheurs, pas chez les éditeurs.

Conclusion : le patch est mort, vive la défense en profondeur

Le modèle « éditeur patche, client applique, problème réglé » s'effondre depuis deux ans. Il a été remplacé par un jeu permanent de « patch incomplet, exploitation continue, patch suivant, exploitation continue ». Tant que les éditeurs n'investiront pas dans le bug variant hunting interne et dans la transparence sur les correctifs partiels, les défenseurs n'ont pas le choix : il faut bâtir des architectures qui survivent à un patch incomplet. Segmentation, micro-périmètres, EDR avec règles comportementales et non plus signatures, monitoring serré des coercitions d'authentification.

C'est plus cher. C'est plus lent. C'est moins sexy à présenter en COMEX. Mais c'est la seule réponse rationnelle à un environnement où le patch ne tient plus six mois. Les RSSI qui auront accepté ce changement de paradigme en 2026 dormiront mieux en 2027. Les autres recevront des appels nocturnes de Qilin, APT28 ou de leurs successeurs.