
Технический анализ и proof-of-concept для уязвимости внедрения команд в рендеринге Markdown в Блокноте Windows, срабатывающей при Control+Click на специально созданных ссылках, с обсуждением сценариев эксплуатации и мер защиты.
*Этот контент соответствует части того, что предоставляется через Ежемесячный отчёт для подписчиков PatchPoint.
Microsoft раскрыла исправление для уязвимости RCE в Блокноте в феврале 2026 года. Уязвимость представляет собой уязвимость внедрения команд, которая возникает в Блокноте и срабатывает при щелчке по ссылке вместе с клавишей Control при рендеринге Markdown в Windows Блокноте. Уязвимость можно объяснить просто. При переходе по ссылке через Control+Click в Markdown отсутствует фильтрация схемы URI, поэтому выполняется приложение-обработчик для этого протокола, и при этом не появляется диалоговое окно предупреждения. Затронутый диапазон уязвимости выглядит следующим образом.
Уже исправленную версию и неисправленную версию можно проверить следующим образом.
В FAQ MSRC объясняется следующее.
Q. Как злоумышленник мог бы использовать эту уязвимость?
A. Злоумышленник мог бы обманом заставить пользователя щёлкнуть по вредоносной ссылке внутри файла Markdown, открытого в Блокноте, что приведёт к запуску непроверенных протоколов, которые загружают и выполняют удалённые файлы.
Q. Согласно метрике CVSS, вектор атаки — сеть (AV:N), и требуется взаимодействие с пользователем (UI:R). Каков целевой контекст удалённого выполнения кода?
A. Вредоносный код выполнялся бы в контексте безопасности пользователя, открывшего файл Markdown, предоставляя злоумышленнику те же разрешения, что и у этого пользователя.
Вышеуказанный контент содержит возможные и невозможные сценарии. Если сразу перейти к выводу, в «нормальной ситуации» это сделать непросто.



Если сразу перейти к выводу, для успешной атаки требуется дополнительная уязвимость, что делает этот вектор атаки неэффективным. Это связано с тем, что поиск среды, требующей взаимодействия с пользователем, включая ограниченную версию + Загрузка -> Выполнение -> Просмотр Markdown -> Control+Click, а затем связывание ещё одной уязвимости для атаки, очень неэффективен.
Ниже приведено подробное объяснение того, почему в нормальной ситуации это сложно. Обычно, когда мы говорим об RCE, могут возникать проблемы, когда код выполняется удалённо, когда жертва загружает файл и выполняет его. Обычно проблемой в этом случае становится MoTW (Mark of the Web).
При загрузке из интернета, если проверить с помощью команды dir /r следующим образом, настройка MoTW (ZoneID=3) регистрируется через ADS.


Если MoTW установлен таким образом, появится окно для взаимодействия с пользователем, соответствующее своего рода сообщению безопасности, как показано ниже.

Если щёлкнуть по диалоговому окну предупреждения, оно действительно выполняется следующим образом.

Затем для этого необходимо рассмотреть метод обхода MoTW. Поскольку эта уязвимость не является LPE, она создаётся с теми же привилегиями, и если так, то полезная нагрузка атаки, созданная в локальной среде, была бы бессмысленной.
Для обхода MoTW существует несколько методов. Обычно используемые методы — WebDAV и метод с использованием SMB через UNC Path.
Метод, который возможен, но сложен, — использование нативной схемы, как в уязвимости Follina. Самый базовый ms-* — хороший метод. (Однако я считаю, что уязвимости ms-* определённо могут работать более полезным образом.) Поскольку Teams также устанавливается по умолчанию в наши дни, схема msteams: также работает, и схема odopen для OneDrive также работает.

Как показано выше, если выполнить ms-mmsys, он работает в соответствии с методом, зарегистрированным в реестре, без отдельного диалогового окна аутентификации.

Имейте в виду, что это означает, что это возможно, но поскольку это фактически территория новой уязвимости, представлена только методология.
Если пользователь настроит это, может существовать ещё один сценарий. Это метод через HTML с ActiveX/VBScript. Можно использовать схему «IE.HTTP:», но проблема в том, что IE не установлен по умолчанию, что является большой проблемой. 😂 Необходимо настроить отдельную конфигурацию для перенаправления на IE, а также ActiveX должен быть настроен для работы в IE. 😁

Это связано с тем, что ActiveX не работает в Edge, как показано выше. В заключение, это очень ограничено.
Аналогично, в наши дни при установке приложений становятся доступными различные схемы. Например, для пользователей WinSCP будет применяться схема sftp:, а для людей, установивших Adobe Acrobat, будет доступна схема acrobat:. Если из такой схемы можно выполнить полезную команду, это может стать проблемой.
Вкратце, эта уязвимость может быть вектором удалённого выполнения кода. Каждый раз, когда появляется новая функция, любой продукт был целью для атак и проверок, и эта ошибка, появившаяся на этот раз, соответствует одной из таких уязвимостей. 😀