Patched Twice, Still Bypassed: New NTLM Leak (CVE-2025-59214) 

Executive Summary 

As part of our ongoing security research at Cymulate Research Labs, I discovered a zero-click NTLM credential-leakage vulnerability that bypasses Microsoft’s patch for CVE-2025-24054. A patch was released and assigned to CVE-2025-50154. But it turned out that the patch wasn’t working. 

The bypass, now CVE-2025-59214, allows an attacker to extract NTLM hashes without any user interaction, even on fully patched systems. By exploiting a subtle gap left in the mitigation, an attacker can trigger NTLM authentication requests automatically, enabling offline cracking or relay attacks to gain unauthorized access. 

The risk is significant: NTLM relay attacks can lead to privilege escalation, lateral movement and RCE with no user interaction. It increases the attack surface for organizations that rely especially when targeting high-value accounts. Since this exploit requires zero user interaction, it increases the attack surface for organizations relying solely on Microsoft’s April patch for protection. 

We responsibly disclosed our findings to the Microsoft Security Response Center (MSRC), and the vulnerability has been officially recognized with its own CVE identifier. A new security update is expected to fully address the issue (October 14, 2025). 

What is NTLM? 

NTLM, short for New Technology LAN Manager, is Microsoft’s family of authentication protocols used to confirm user identities and safeguard network communications. It works through a direct client–server “challenge/response” process, the server issues a challenge, and the client proves its identity without ever transmitting the actual password across the network. 

While NTLMv2 is protected against precomputed attacks like rainbow tables and pass-the-hash, captured hashes can still be exploited. Attackers may try to brute-force them offline or use a relay attacks, a man-in-the-middle method where the stolen hash is passed to another service to log in as the user. If the compromised account has elevated privileges, this can quickly lead to privilege escalation and lateral movement across the network. 

The vulnerability was first reported as CVE-2025-24054, the patch was first bypassed in our report on CVE-2025-50154, and bypassed again in our new report, CVE-2025-59214. 

How Did Microsoft Respond to the NTLM Leak? 

Microsoft decided in March 2025 to release the CVE-2025-24054 patch, preventing the use of a well-known technique: an NTLMv2-SSP hash disclosure using shortcut file creation in explorer.exe. 

We reported on April 2025 that the patch didn’t work for LNK files. Specifically, when the Target value is a UNC path and the Icon value is the default shell32.dll file, the NTLMv2-SSP hash still leaks. The vulnerability was assigned CVE-2025-50154, and we published a blog explaining the flaw. A proof of concept (POC) is available on GitHub.  

However, shortly after the update of Aug. 12, 2025, we were contacted by 0patch, who informed us that after running tests on fully updated systems, the vulnerability still exists. 

0patch is a trusted security platform that delivers micro patches - tiny, hot-applied fixes that close vulnerabilities instantly without needing system reboots or full software updates. 

We created a lab with a fully patched Windows Server 2022 machine (updated with KB5063880), and reproduced the vulnerability. 

On the first machine, we created the LNK file. We used impacket-smbclient from a kali machine to upload the LNK file to a share opened by a Domain Admin session. Right after the file upload, the Domain Admin’s NTLMv2-SSP hash was disclosed to our listening Responder server.  

After disclosing the vulnerability to Microsoft, it has been recognized and assigned CVE-2025-59214. The POC remains the same.  

But the question remains: How for the third time does the vulnerability still exist and why did the patch not work? 

We asked MSRC for more explanations and received the following answer: 

“”” 

• The original fix for 0-click binary vulnerabilities had a gap - the security check code is allowed to execute only once, hence for icon path it worked properly but for target value it is ignored. 
• Due to above limitation, the code took a different execution path for target value in UNC path. 
• This alternative path checked for UNC path existence and inadvertently leaked NTLM authentication hashes. 

“”” 

It looks like the function responsible for checking whether a UNC path exists checks only the Icon value. But then what changed after CVE-2025-50154? 

It wasn’t clear for many reasons: 

• What actually changed after the CVE-2025-50154 patch? (For example KB5063880)? 
• Does Microsoft run tests to validate these security updates? If yes, how did the vulnerability still exist even after the patch? 
• Can we rely blindly on patches when nothing changes, even after a bypass report (CVE-2025-50154)? 
• We also observed that the zero-click binary download no longer occurs. Does it mean that in contrary to what MSRC said, the target value is not ignored? 

While we are still trying to understand it from MSRC, we understand that threat validation is essential to prevent missed fixes, and assuming that patches are always enough to prevent new zero-days is a mistake. 

Conclusion 

The discovery of a fresh bypass proves that even patched vulnerabilities can remain exploitable when security checks aren’t applied consistently. Despite fixes for CVE-2025-24054 and CVE-2025-50154, attackers can still trigger NTLM hash leaks and silently stage remote payloads in zero-click scenarios. 

This persistence of exposure highlights how minor oversights can reopen critical attack paths - turning credential theft and stealthy payload delivery into a single, powerful compromise chain. It underscores the need for rigorous patch validation, defense-in-depth, and continuous adversarial testing to ensure that "fixed" doesn’t mean "secure."