Une faille subsistant après le patch zéro jour de février est déjà exploitée, et la lenteur des cycles de patch tant au niveau du gouvernement que des entreprises donne le dessus aux attaquants.
Microsoft et l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) ont tiré la sonnette d’alarme concernant une vulnérabilité d’usurpation d’identité du shell Windows qui est déjà exploitée par des attaquants. On ne sait pas encore par qui, mais les principaux suspects sont des pirates informatiques en Russie.
La CISA a exigé que toutes les agences fédérales corrigent cette vulnérabilité, désignée CVE-2026-32202, d’ici le 12 mai. Selon un avis de Microsoft, l’exploitation de la faille pourrait conduire à l’accès à des données sensibles, mais les attaquants ne pourraient pas prendre le contrôle du système.
Cependant, un expert en sécurité a averti que l’écart considérable entre le moment où Microsoft a identifié le bug et la date à laquelle les systèmes doivent être corrigés entraîne un risque accru.
L’écart entre les correctifs
Lionel Litty, RSSI de la société de sécurité Menlo, a déclaré qu’un correctif incomplet pour CVE-2026-21510 qui a entraîné le problème suivi comme CVE-2026-32202 ajoute au problème. « C’est un thème depuis de nombreuses années. Une vulnérabilité existe et le fournisseur n’a pas été suffisamment minutieux pour la traiter, donc une petite variation n’a pas été entièrement corrigée. Ce qui se passe normalement, c’est qu’ils ont traité la vulnérabilité principale, mais il y a toujours des effets secondaires. » Le résultat est qu’il y a un retard supplémentaire dans la résolution complète du problème pendant qu’une nouvelle mise à jour est développée.
Le gros problème, a déclaré Litty, est ce que l’on appelle le patch gap. Il a déclaré qu’au départ, il y avait un écart entre le moment où les fournisseurs découvrent une vulnérabilité et le moment où ils publient un correctif, et il existe également un écart ultérieur entre le correctif publié et le moment où les organisations terminent la mise à jour. Par exemple, a-t-il noté, si une mise à jour interrompt le travail des utilisateurs, ceux-ci peuvent hésiter à l’appliquer. « Nous pouvons constater sur notre plateforme que de nombreux utilisateurs ne mettent pas à jour pendant des semaines, voire des mois », a-t-il déclaré.
Il a souligné que les vendeurs eux-mêmes agissent efficacement. Mais, a-t-il déclaré, « en tant que RSSI, je dois décider du niveau de douleur à infliger à nos utilisateurs ».
Un équilibre difficile
Erik Avakian, conseiller technique chez Info-Tech Research Group, a noté que lorsqu’elle a fixé la date limite de mise à jour des correctifs, la CISA avait fonctionné conformément aux lignes directrices établies dans la directive opérationnelle contraignante (BOD) 22-01, qui oblige les agences fédérales américaines à corriger les vulnérabilités dans les délais indiqués dans la politique, qui vont de 14 à 21 jours.
« En cas d’exploitation à haut risque, la CISA peut raccourcir le délai à trois jours », a-t-il précisé. « Mais dans le cas de CVE-2026-32202, le score CVSS a été évalué à 4,3, et même si la vulnérabilité a été activement exploitée, la note n’atteint pas le seuil politique pour un cycle de correctif plus rapide. Dans ce cas, CISA a accordé un délai de 14 jours, ce qui répond à sa norme de calendrier agressive basée sur l’évaluation du fournisseur. «
Il a ajouté qu’il existe en effet un argument selon lequel le délai de 14 jours pour corriger une vulnérabilité activement exploitée dans la nature est trop long. Mais, a-t-il ajouté, « je suppose que dans ce cas, la raison pour laquelle il n’a pas été élevé au niveau d’un cycle de patch de type directive d’urgence (qui nécessiterait aussi peu que 48 à 72 heures pour le patch) est due à la note de Microsoft, ainsi qu’à plusieurs autres facteurs ».
Avakian a expliqué son raisonnement : « Premièrement, les organisations peuvent contribuer à atténuer le risque sans appliquer de correctif complet en bloquant certains ports pour le trafic au niveau du périmètre du pare-feu », a-t-il déclaré. « Ce type de contre-mesure contribue à réduire le risque pendant que la fenêtre de mise à jour des correctifs de 14 jours tourne. La fenêtre plus longue donne aux testeurs plus de temps pour tester les correctifs appliqués correctement dans un environnement de test/stade avant de passer en production. »
Deuxièmement, a-t-il déclaré, « c’est une chose (pour l’informatique) de mettre rapidement à jour les systèmes, mais c’en est une autre lorsqu’ils sont précipités, car cela comporte un risque supplémentaire involontaire de panne des systèmes et des applications critiques en cas de problème ou si le correctif n’a pas été testé correctement. »
Avakian reconnaît que les RSSI sont confrontés à un exercice d’équilibre difficile, dans lequel ils doivent peser le risque et la stabilité des systèmes.
Et, comme Litty l’a souligné, la situation est en constante évolution ; l’émergence de l’IA posera davantage de problèmes à l’avenir. « Nous constatons un écart de plus en plus grand à mesure que l’IA devient une partie du problème », a-t-il déclaré, ajoutant que l’utilisation de l’IA signifie que les personnes ayant moins de compétences techniques sont capables d’exploiter les systèmes, et ce, plus rapidement. Les RSSI ne devraient donc pas supposer que les attaques sophistiquées proviennent des États-nations. Il faut un changement de mentalité au sein des organisations pour faire face à cela.
« On ne peut plus passer quelques semaines à tester une mise à jour puis à la mettre en œuvre : il faut faire les choses beaucoup plus rapidement », a-t-il déclaré.
