{"uuid": "b6a938d3-d930-4a2d-bb35-8f0eac380d02", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-33053", "type": "seen", "source": "https://infosec.exchange/users/wdormann/statuses/116533862391306228", "content": "Let's talk about Windows .URL (InternetShortcut) files.\nLast 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 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 (\ud83d\ude02), 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 (\ud83d\ude02).\nMicrosoft recognized the vulnerability and published an update in the form of CVE-2025-33053.\nIf we were to believe the Microsoft documentation at the time, \n\nWhen the user clicks the icon, the browser is launched and displays the site associated with the shortcut.\nBut 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.\nOh, 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.\nI 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?  \nBless your innocent soul.  Per MSRC:\n\nWhen 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.\nOkie dokie.  I'm sure Windows users surely appreciate this.  But what about the incorrect documentation?  After my prodding, they updated the wording:\n\nWhen the user clicks the icon, the URL path is opened by the handler application, typically the user's default web browser.\nLeaving in the quite misleading first sentence:\n\nThe Internet shortcut object is used to create desktop shortcuts to Internet sites.\n(An \"Internet site\" is a web page, right?)\nHow 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.\nWhat can we do about it?\nAt 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.\nMore 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.\nThis 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\nDo 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.", "creation_timestamp": "2026-05-07T14:53:50.896942Z"}