Microsoft ha solucionado una vulnerabilidad de ejecución remota de código (RCE) en el nuevo Notepad de Windows 11 que permitía ejecutar programas locales o remotos simplemente al hacer clic en enlaces Markdown especialmente diseñados, sin mostrar advertencias de seguridad del sistema.
La falla, identificada como CVE-2026-20841, fue corregida durante el Patch Tuesday de febrero de 2026 y afectaba a versiones 11.2510 y anteriores de Notepad.
El problema ha generado gran interés en la comunidad de ciberseguridad debido a lo inesperado del vector de ataque: sobre un simple archivo .md.
¿Qué cambió en Notepad para que esto fuera posible?
Con Windows 11, Microsoft eliminó WordPad y modernizó Notepad para convertirlo en algo más que un editor de texto plano.
Entre las mejoras se incluyó:
- Soporte para Markdown
- Visualización enriquecida
- Enlaces clicables
- Funciones básicas de formato (negrita, listas, etc.)
El soporte Markdown permite abrir y guardar archivos .md, utilizando sintaxis como:
**Texto en negrita**
[Enlace](https://example.com)
El problema apareció cuando Notepad comenzó a interpretar estos enlaces como elementos clicables sin aplicar restricciones adecuadas a los protocolos utilizados.
CVE-2026-20841: cómo funcionaba la vulnerabilidad
Según el boletín de seguridad de Microsoft, el fallo se debía a: “Improper neutralization of special elements used in a command (‘command injection’).”
En términos prácticos:
- Un atacante creaba un archivo
.mdmalicioso. - Insertaba enlaces usando protocolos como:
file://,ms-appinstaller://,ms-settings://,mailto:oms-search:. - La víctima abría el archivo en Notepad en modo Markdown.
- Al hacer Ctrl + clic sobre el enlace, el sistema ejecutaba directamente el recurso apuntado.
- No aparecía ninguna advertencia de seguridad de Windows.
Eso significa que era posible:
- Ejecutar un archivo
.exelocal - Lanzar un instalador remoto
- Invocar protocolos especiales del sistema
- Cargar ejecutables desde recursos SMB remotos
Todo ello con los mismos privilegios del usuario que abrió el archivo.
¿Por qué es considerada ejecución remota de código?
Aunque el usuario debía hacer clic manualmente, Microsoft clasifica el fallo como RCE porque:
- Permitía ejecutar código arbitrario
- No mostraba advertencias de seguridad
- Podía aprovecharse mediante ingeniería social
- Permitía ejecutar archivos desde ubicaciones remotas
El código se ejecutaba en el contexto de seguridad del usuario, lo que significa que el impacto dependía del nivel de privilegios de la víctima.
¿Cómo ha solucionado Microsoft el problema?
Luego de la actualización de febrero de 2026:
- Notepad muestra una advertencia cuando se hace clic en enlaces que no utilizan
http://` ohttps://`. - Protocolos como
file:,ms-appinstaller:,ms-settings:y similares ahora generan un cuadro de confirmación.
Es decir, el comportamiento ya no es silencioso.
Sin embargo, Microsoft no ha bloqueado completamente los protocolos no estándar, lo que deja abierta la posibilidad de ataques basados en ingeniería social si el usuario acepta manualmente la advertencia.
Impacto real para los usuarios
La buena noticia es que:
- Notepad se actualiza automáticamente a través de Microsoft Store.
- La mayoría de sistemas ya deberían estar protegidos.
- No se han reportado campañas masivas explotando activamente la vulnerabilidad.
El riesgo principal estaba en escenarios de:
- Phishing dirigido
- Ataques en entornos corporativos
- Distribución de archivos Markdown maliciosos
Implicaciones de seguridad más amplias
Este incidente expone un patrón recurrente:
- Se añade funcionalidad moderna a aplicaciones simples.
- Se amplía la superficie de ataque.
- Protocolos del sistema se vuelven explotables indirectamente.
- La ingeniería social se convierte en vector crítico.
Notepad pasó de ser un editor de texto inofensivo a un posible punto de ejecución indirecta.
La lección es clara: cualquier aplicación que interprete enlaces o protocolos debe implementar validaciones estrictas.
¿Debió Microsoft bloquear los protocolos no estándar?
Algunos expertos señalan que lo más seguro habría sido:
- Permitir únicamente
httpyhttps - Bloquear completamente
file://y URIs especiales
La decisión de mostrar solo advertencias deja la protección final en manos del usuario, lo cual históricamente no es el mecanismo más robusto frente a ataques de ingeniería social.