patchpoint/cve-2026-20841Analyse technique et preuve de concept pour une vulnérabilité d'injection de commandes dans le rendu Markdown du Bloc-notes Windows, déclenchée via un clic Contrôle+clic sur des liens malveillants, avec discussion des scénarios d'exploitation et des mesures d'atténuation.
*Ce contenu correspond à une partie de ce qui est fourni via le Rapport Mensuel pour les abonnés PatchPoint.
Microsoft a divulgué un correctif pour une vulnérabilité RCE dans Notepad en février 2026. La vulnérabilité est une vulnérabilité d'injection de commandes qui se produit dans Notepad, déclenchée lorsqu'un lien est cliqué avec la touche Contrôle dans le rendu Markdown du Bloc-notes Windows. La vulnérabilité peut être expliquée simplement. Lors de l'accès à un lien via un clic Contrôle dans Markdown, il n'y a aucun filtrage sur le schéma d'URI, donc l'application de gestion pour ce protocole est exécutée et aucune boîte de dialogue d'avertissement n'apparaît pour cela. La portée affectée de la vulnérabilité est la suivante.
La version déjà corrigée et la version non corrigée peuvent être vérifiées comme suit.
La FAQ de MSRC explique ce qui suit.
Q. Comment un attaquant pourrait-il exploiter cette vulnérabilité ?
R. Un attaquant pourrait inciter un utilisateur à cliquer sur un lien malveillant dans un fichier Markdown ouvert dans Notepad, provoquant le lancement de protocoles non vérifiés qui chargent et exécutent des fichiers distants.
Q. Selon la métrique CVSS, le vecteur d'attaque est réseau (AV:N) et une interaction utilisateur est requise (UI:R). Quel est le contexte cible de l'exécution de code à distance ?
R. Le code malveillant s'exécuterait dans le contexte de sécurité de l'utilisateur qui a ouvert le fichier Markdown, donnant à l'attaquant les mêmes autorisations que cet utilisateur.
Le contenu ci-dessus comporte des scénarios possibles et impossibles. Pour énoncer la conclusion en premier, ce n'est pas facile dans une « situation normale ».
Pour énoncer la conclusion en premier, une vulnérabilité supplémentaire est nécessaire pour que l'attaque réussisse, ce qui en fait un vecteur d'attaque inefficace. Cela est dû au fait que trouver un environnement nécessitant une interaction utilisateur incluant une version limitée + Téléchargement -> Exécution -> Affichage Markdown -> Clic Contrôle, puis enchaîner une autre vulnérabilité pour attaquer, est très inefficace.
Voici une explication détaillée de ce qui a été dit sur le fait que c'est difficile dans une situation normale. Généralement, quand on parle de RCE, il peut y avoir des problèmes où du code est exécuté à distance lorsqu'une victime télécharge un fichier et l'exécute. Généralement, ce qui devient un problème à ce stade est MoTW (Mark of the Web).
Lorsqu'il est téléchargé depuis Internet, si vous vérifiez en utilisant la commande dir /r comme suit, le paramètre MoTW (ZoneID=3) est enregistré via ADS.
Si MoTW est défini de cette manière, une fenêtre d'interaction utilisateur correspondant à une sorte de message d'avertissement de sécurité apparaîtra comme suit.
Si vous cliquez sur la boîte de dialogue d'avertissement, elle s'exécute effectivement comme suit.
Ensuite, pour cela, une méthode pour contourner MoTW doit être envisagée. Étant donné que cette vulnérabilité n'est pas une LPE, elle est créée avec les mêmes privilèges, et si c'est le cas, une charge utile d'attaque conçue dans un environnement local serait dénuée de sens.
Pour contourner MoTW, il existe plusieurs méthodes. Les méthodes couramment utilisées sont WebDAV et la méthode utilisant SMB via le chemin UNC.
Une méthode possible mais difficile consiste à utiliser un schéma natif comme la vulnérabilité Follina. Le ms-* le plus basique est une bonne méthode. (Cependant, je crois que les vulnérabilités ms-* peuvent certainement fonctionner de manière plus utile.) Étant donné que Teams est également installé par défaut de nos jours, le schéma msteams: fonctionne également, et le schéma odopen pour OneDrive fonctionne aussi.
Comme montré ci-dessus, si vous exécutez ms-mmsys, il fonctionne selon la méthode enregistrée dans le registre sans aucune boîte de dialogue d'authentification séparée.
Veuillez garder à l'esprit que cela signifie que c'est possible, mais comme cela relève en réalité du territoire d'une nouvelle vulnérabilité, seule la méthodologie est présentée.
Si l'utilisateur le configure, il peut y avoir encore un autre scénario. C'est une méthode via HTML avec ActiveX/VBScript. Vous pouvez utiliser le schéma « IE.HTTP: », mais le problème est qu'IE n'est pas défini comme navigateur par défaut, ce qui est un gros problème. 😂 Un paramètre séparé doit être configuré pour rediriger vers IE, et ActiveX doit également être configuré pour fonctionner dans IE. 😁
Cela est dû au fait qu'ActiveX ne fonctionne pas dans Edge comme montré ci-dessus. En conclusion, c'est très limité.
De même, de nos jours, lorsque vous installez des applications, divers schémas deviennent disponibles. Par exemple, pour les utilisateurs de WinSCP, le schéma sftp: serait appliqué, et pour les personnes qui ont installé Adobe Acrobat, le schéma acrobat: serait accessible. Si une commande utile peut être exécutée à partir d'un tel schéma, cela pourrait être un problème.
En résumé, cette vulnérabilité peut être un vecteur d'exécution de code à distance. Chaque fois qu'une nouvelle fonctionnalité apparaît, tout produit a été une cible d'attaque et de vérification, et ce bug qui est sorti cette fois correspond à l'une de ces vulnérabilités. 😀