Let's talk about Windows .URL (InternetShortcut) files.
Last year there was discussion about a vulnerability in how Windows handles .URL files. Specifically, when a .URL file specifies a WorkingDirectory directive, an otherwise harmless app being launched would load DLLs from the remote (e.g. WebDAV) server specified. You know, being the current working directory of the app being launched and all. This vulnerability was being exploited in the wild, and it worked well because it bypassed annoying (to attackers) things like SmartScreen. Sure, it required the victim to click Open on a dialog saying Type: Unknown File Type (馃槀), but we all know that users are click-happy, so this is fine. Besides, the file clearly has a .pdf extension, so it should be safe (馃槀).
Microsoft recognized the vulnerability and published an update in the form of CVE-2025-33053.
If we were to believe the Microsoft documentation at the time,
When the user clicks the icon, the browser is launched and displays the site associated with the shortcut.
But wait...
How did this .URL file cause a program to be launched? The URL= parameter specifies a website address to be loaded in the browser.
Oh, naive child. Obviously a .URL file can directly point to code on a remote (e.g. WebDAV) server. This technique is also being exploited ITW as well.
I reported this to Microsoft, as this has the EXACT SAME IMPACT as CVE-2025-33053. So if that's a vulnerability, then this too is a vulnerability, right?
Bless your innocent soul. Per MSRC:
When the Shell invokes an app from a remote share, it's expected that you will see the legacy Windows Security prompt, not the SmartScreen one. SmartScreen Application Reputation (AppRep) evaluation applies to locally downloaded files that bear an Internet Zone mark of the web. It is not meant to apply to execution of files from Network Shares.
Okie dokie. I'm sure Windows users surely appreciate this. But what about the incorrect documentation? After my prodding, they updated the wording:
When the user clicks the icon, the URL path is opened by the handler application, typically the user's default web browser.
Leaving in the quite misleading first sentence:
The Internet shortcut object is used to create desktop shortcuts to Internet sites.
(An "Internet site" is a web page, right?)
How can CVE-2025-33053 warrant a CVE, while the behavior I described has the exact same trigger and impact is not CVE worthy? That's pretty easy. Microsoft assigns CVEs to updates, not vulnerabilities. They are the decider as to what is a vulnerability and what is not.
What can we do about it?
At the very least, turn off the Windows feature that hides file extensions, even if you have the option turned on to see file extensions. The disdain that Microsoft has for Windows users is tangible here. On what planet would I not want to see the actual extension of a file? Go to HKCU\InternetShortcut and delete the NeverShowExt value. After this, your pwned.pdf file will reveal its true self as being pwned.pdf.url.
More powerful protection would be to block the ability to receive .URL files via email, web browsers, etc. There is no workflow that I can imagine that requires a user to double-click on a .URL file that came from the internet.
This screen recording is a Windows 11 system that has no internet connectivity. The fact that no warning was displayed that SmartScreen cannot be reached is evidence that SmartScreen is not in play at all. And that dialog...Do you want to open this file?
andType: Unknown File Type
Do you think that users are presented with enough information to make an informed security decision? Of course not. But obviously we all know that we can't rely on users making informed security decisions in general. Don't put users in that position.
