Microsoft fixes years old actively exploited .lnk flaw in Windows
Microsoft has addressed a security flaw in Windows that has been exploited since at least 2017. The company has not made an official announcement about the fix, but it was spotted by 0patch.
The flaw is known as the Microsoft Windows LNK File UI Misrepresentation Remote Code Execution Vulnerability and has been tracked as CVE-2025-9491. The fix was included in the November batch of updates for Windows.
The vulnerability has a security score of 7.7, meaning it represents a high risk, and it is not clear why it has taken so long for Microsoft to fix it. The description of the problem appears on the NIST website:
Microsoft Windows LNK File UI Misrepresentation Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Microsoft Windows. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of .LNK files. Crafted data in an .LNK file can cause hazardous content in the file to be invisible to a user who inspects the file via the Windows-provided user interface. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25373.
But while 0patch has drawn attention to Microsoft giving the vulnerability some work, it is a little critical of the approach taken. The third-party patching outfit explains the issue says:
A .lnk file structure allows the Target arguments to be a very long string (tens of thousands of characters), but the Properties dialog only shows the first 260 characters, silently cutting off the rest.
So it is possible to construct a .lnk file that runs a reeeeealy long PowerShell or BAT script, but only the first 260 characters of it would be shown to the user who viewed its properties. And these characters could be mostly "whitespace" characters to push the interesting bits entirely out of the Target field - even if the user scrolled to the very end.
Microsoft did not consider this to be a vulnerability, hence the massive delay in doing anything about it. 0patch spotted something, though:
However, we noticed something did change with November Windows Updates: now, the Properties dialog of a .lnk file shows the entire Target command with arguments, no matter how long it is. The theoretically-up-to-32k-character-long string is now shown in the same single-line field that can't even reveal an entire modest-sized command without selecting some text and moving the mouse left or right. But okay, at least one can select all, copy and paste the string to a text editor.
The issue was apparently demoted from vulnerability to functional bug, silently fixed without an advisory, and trust in the user interface was restored.
Arguably, if the problem was defined as "The properties dialog does not always show exactly what will be executed," it would indeed have been resolved. But this approach was weird: namely, it has always been the case that the "ordinary" way to create or modify a Windows shortcut - via Explorer user interface - only allowed you to enter up to 260 characters to the Target field. The only way for this string to be longer is to create the shortcut programmatically, e.g. using Windows API. (And some applications may be creating such legitimate shortcuts for its own use.) So how much would showing all Target characters in a small field improve chances for victims targeted in actual attacks?
It should come as little surprise that 0patch has a fix of its own; one that it says properly addresses the security flaw. You can find out more in the related blog post here.
Image credit: HJBC / depositphotos
