Good day fine folks of the Internet! While it's the season of winter holidays of many kinds for many folks, some of us at GAYINT observe Festivus, which falls on this day, December 23! And the most important part of Festivus is undoubtedly the airing of grievances. Some people would say, "But GAYINT, you're a bunch of internet security nerds, aren't you constantly airing grievances?" And they'd be right. But today's a designated holiday for it.
To wit, we've got some problems with the CVE mentioned in the title of this blog, and now, you're gonna hear about 'em!
Let's start from the beginning: in March 2025, the folks at TrendMicro's Zero Day Initiative published a research piece along with an advisory filled with as many buzzwords as they could pack in, detailing a "zero day exploit" targeting "a Windows .lnk file vulnerability that enables hidden command execution." This "exploit" "...[H]as been exploited by state-sponsored APT groups from North Korea, Iran, Russia, and China." They proceed to rattle off a bunch of threat group names that overlap with other vendor's names and sprinkle in "APT" a few more times. If you're playing along at home, feel free to reference the Official GAYINT Threat Actor Crosswalk.
Well, this is some top notch work - the Big 4 of Western cyber threat tracking, all exploiting this Windows 0-day - surely this will make headlines. So where's the CVE? The answer is, there wasn't one. TrendMicro tracked this "vulnerability" with their own designator, ZDI-CAN-25373, which is meaningless to anyone who is not TrendMicro. But syntactically, it kind of looks like a CVE designator? We guess?
Puzzling, no? Well, the first clue is on the "advisory" link that details a 6-month disclosure timeline, beginning in September of 2024 and ending in March of 2025. Based on that timeline, it took Microsoft roughly a week to conclude that they weren't going to action anything related to what TrendMicro researchers reported. TrendMicro follows up in November with "additional information", and Microsoft takes a break for the holidays (presumably Festivus) before responding in March that their assessment stays unchanged. Just shy of 5 months after, TrendMicro reaffirms their stance that ain't no one going to tell them what to do, and says they'll be publishing the research.
The next clue as to what's going on here lies an eye-watering 2/3 of the way down through the main article that has the, er, technical details of the "exploit", past all the bluster in the first 2/3 about what threat clusters have leveraged it, and in what regions, and what they're targeting, and likely what they ate for lunch last week, as well as a short tangent about how LNK files work (because Windows Internals is just too boring of a read).
ZDI-CAN-25373's technical details are as follows, verbatim from the report:
"To exploit ZDI-CAN-25373, the threat actors carefully crafted .lnk files with padded whitespace characters within the COMMAND_LINE_ARGUMENTS structure. If a user inspects a .lnk file containing this malicious padding, Windows will not be able to show the malicious arguments within the allotted space in the user interface. The impact of this exploit is that the command line arguments that will be executed by the .lnk file are completely hidden from the user’s view. To inspect the Target field of samples exploiting ZDI-CAN-25373 and the contents of the COMMAND_LINE_ARGUMENTS structure, third-party tools are required."
We think we see why Microsoft didn't bother answering TrendMicro's emails on this one for four months.
The argument presented by TrendMicro is that this "vulnerability" exists because if you haphazardly yeet (they said "carefully", we disagree) newline, space, tab, or other characters that match a regex '\\s' ("malicious padding" - what makes these characters malicious?) before the arguments in an LNK file, the Windows right-click -> "Properties" dialog will not show the actual contents of that section to the user.
Or, put more simply, inserting space characters into a text field will have the effect of... rendering space characters, in that text field.
Nation-state threat actor exploited zero-day, baby.
There's another bone to pick here as well, asserting that third-party tools are required to view the contents of the space-filled structure. We can't be certain about their definition of "third-party", but this is trivial in PowerShell, which to us queer nerds seems first-party on Windows:
Get-Content filename.lnk | Format-Hex
To TrendMicro's point, there is no way to navigate past the space characters displayed in the "Properties" dialog in the relevant section of the interface. Point taken, but that's a user interface bug, not a zero-day exploit. Calling a spade a birthday cake does not make it taste better when you bite into it. LNK files execute the target and command line arguments they’re configured with. It's how they work in Windows. So, shockingly, computers execute code when asked to!
We won't put too sharp a point on this, but nowhere in TrendMicro's writeup do they explain where any security boundary within Windows is bypassed. Partially because that simply is not happening, and partially because any time anyone claims to bypass a security boundary in Windows, Microsoft sternly wags their finger at researchers and reminds them that what they bypassed actually wasn't really intended to be a security boundary despite all documentation and behavior to the contrary.
Now, this is all well and good, but when does the CVE come into play? If you already looked it up, you know, but for those too absorbed in this little blog of ours, it was published in August 2025. This record was later updated in the height of spooky season when Microsoft published their own advisory on October 31, 2025. This is about 13 months after TrendMicro initially reported the issue privately, via established channels.
Microsoft, two months after the CVE was published, had this to say:
"We appreciate the work of ZDI in submitting this report under a coordinated vulnerability disclosure. We have investigated this report and determined that it does not meet the bar for classification as a vulnerability...Due to the user interaction involved and the fact that the system already warns users that this format is untrusted, Microsoft does not consider this a vulnerability."
The entire comment is eyebrow-raising, not in the least because the CNA (CVE Numbering Authority, the organization that assigned the CVE and reported it to the NVD) is none other than Zero Day Initiative, a group within TrendMicro, responsible for this research. Usually, you don’t use your own CNA for a vulnerability unless the company that owns the product is not also a CNA. So, what's happened?
In no case do we ever gotta hand it to Microsoft, but in our view, they're on the correct side of this. Coordinating a vulnerability disclosure with a vendor is a good thing that everyone has to do. It seems underhanded and self-aggrandizing to respond to being denied a CVE by another vendor by simply using your own CNA powers to push one to the NVD. This is especially true for something so thin on actual technical details where the root cause is a flaw in the user interface, with no security boundaries bypassed to obtain code execution.
There's something else that factors in as well, and that's the state of media coverage in security. Searching both the ZDI identifier as well as the CVE number yields numerous articles that all print roughly the same information along with some level of snark aimed at Microsoft for not doing enough about this "critical zero-day being exploited by multiple nation state actors for years on end". Someone somewhere in the chain could have stood to call shenanigans on this one far before our merry little band did so with this here blog.
Oh, well. Maybe next year. Or maybe not - the airing of grievances must live on, after all.
Updated: 23 December 2025