They finally did it. Microsoft has successfully over-engineered a text editor into a threat vector.
This CVE is an 8.8 severity RCE in Notepad of all things.
Apparently, the “innovation” of adding markdown support came with the ability of launching unverified protocols that load and execute remote files.
We have reached a point where the simple act of opening a .md file in a native utility can compromise your system.
Yeah I get your thought process, but the second vulnerability is actually just how Windows is designed to work. When Notepad follows a link, it isn’t opening a web page, it’s passing a command directly to the OS shell.
Because Notepad is a trusted native application, it bypasses many of the security checks that a browser has.
If the link uses the file:// protocol to point to an .exe on a remote server, or ms-appinstaller to trigger an install, the OS treats that as a direct instruction to launch that software, so it can trigger an app installation prompt or, depending on the exploit, silently side-load malicious packages.
I can’t think of any good reason why links opened via notepad should be treated as trusted. Or any remote exe being treated as trusted regardless of what program is trying to open it, including the windows app store. If anything, the default behavior should be to download the file or open a prompt. I’d call that the second flaw.
Glad to be away from that platform.
I fully agree, there isn’t a good reason. The issue is that flaw is a systemic one in Windows.
Modern operating systems should be operating under zero trust. The fact that Windows still operates on Intranet Era logic, where if a file is reachable, it’s probably safe, is exactly why these exploits keep happening.
The problem comes down to a Windows API called ShellExecute. When an application like Notepad passes a link to this API, it is effectively saying to the OS, The user wants to open this, figure out how to run it.
Windows looks at it and essentially says, Oh, it’s an .exe on a network share? The user must want to run that software, launch it, rather than, This is executable code from a network location I don’t control, download it and make the user double-click it themselves.
The main reason it does this is for legacy enterprise convenience. Decades ago Microsoft designed Windows so that companies could put internal tools on a shared drive and employees could run them instantly. They prioritised seamlessness over security by assuming the network perimeter was the security boundary, and everything on it was there because they wanted it to be.
Obviously that assumption is dangerous. Like you said, no remote executable should ever be treated as trusted by default, regardless of whether it came from the Store, an SMB share, or a web link. The action of clicking a link should never map directly to execution of code. It should map to retrieval of data. Microsoft basically turned a convenience feature into a permanent vulnerability.