Windows Search Flaw Can Leak NTLMv2 Hashes Through a Single Link Click

Security researchers have disclosed an unpatched Windows Search URI handler issue that can leak a user’s Net-NTLMv2 hash to an attacker-controlled server after a single link click. Huntress says the flaw affects the search: URI handler and uses the crumb=location parameter to trigger outbound SMB authentication.

The issue matters because it does not require malware, file download, or administrator privileges. In Huntress testing, a crafted search: link could make Windows attempt to authenticate to a remote SMB server controlled by the attacker before the user saw an error message.

The behavior sits in the same vulnerability class as CVE-2026-33829, a Windows Snipping Tool vulnerability that Microsoft patched on April 14, 2026. That Snipping Tool flaw allowed sensitive information exposure through a URI handler and received a CVSS 3.1 score of 4.3 Medium.

How the Windows Search NTLM leak works

The Windows Search issue abuses how the search: and search-ms: protocol handlers process scoped search locations. Microsoft’s own Windows Search documentation describes the crumb argument as a way to control the scope of a search, including through a location value.

In normal use, that feature helps Windows search a specific folder or network location. In the attack path described by Huntress, the location points to a remote SMB share controlled by the attacker. Windows then tries to reach that location and can send NTLM authentication material as part of the connection attempt.

The attacker does not receive the user’s plain password. However, a Net-NTLMv2 hash still has value. Attackers may try to relay it to another service or crack it offline, depending on the target environment and password strength.

Why this looks similar to the Snipping Tool bug

The comparison to the patched Snipping Tool vulnerability is important. In the Snipping Tool case, the vulnerable URI handler accepted a remote UNC path through a filePath parameter. In the Windows Search case, Huntress says the search: handler can use crumb=location to reach a remote UNC path.

Both cases involve a crafted link, a Windows URI handler, and outbound SMB authentication. Both require user interaction, but the interaction can be as small as clicking a link in a browser, email, chat message, or document.

The NVD entry for CVE-2026-33829 describes the Snipping Tool issue as sensitive information exposure that allows spoofing over a network. Huntress argues that the Windows Search variant has the same effective impact but has not received the same servicing treatment.

Issue	Component	Trigger	Status
CVE-2026-33829	Windows Snipping Tool	Crafted URI with remote path	Patched by Microsoft
Windows Search URI issue	Windows Search handler	Crafted search: or search-ms: link with remote location	No CVE or fix reported by Huntress

Search and search-ms remain a known attack surface

The Windows Search protocol handlers have appeared in security research before. In 2023, Trellix documented attacks that used the search-ms URI protocol handler to display remote files in Windows Explorer and make them appear more trustworthy to users.

That earlier technique focused on payload delivery. Attackers could use phishing emails, websites, HTML files, or script files to launch a search window showing remote content. The user might then open a malicious shortcut or file while believing it came from a familiar Windows interface.

The newly disclosed issue focuses on NTLM leakage rather than payload delivery. Still, it builds on the same broader problem: Windows protocol handlers can turn a simple link into a system-level action that many users do not expect.

Earlier NTLM leakage research adds context

NTLM leakage through Windows and Microsoft components has remained a recurring security problem. Varonis reported in 2024 that attackers could obtain NTLMv2 hashes through Outlook, Windows Performance Analyzer, and Windows File Explorer techniques.

Varonis also explained why captured NTLMv2 hashes matter. Attackers can try offline brute-force attacks or authentication relay attacks, especially when organizations still rely on NTLM and lack strong mitigations such as SMB signing or outbound SMB restrictions.

Microsoft’s crumb argument reference shows that remote locations are part of the supported search scope model. That makes proper validation important when the same feature can cause Windows to contact an attacker-controlled network path.

What Huntress says Microsoft did

Huntress says it reported the Windows Search issue to Microsoft on April 15, 2026, one day after Microsoft patched the Snipping Tool bug. According to the Huntress report, Microsoft later assessed the issue as Moderate and below the servicing bar.

The disclosure timeline says Microsoft confirmed that servicing decisions for Moderate cases can happen on a case-by-case basis. In practice, that means the Snipping Tool variant received a CVE and patch, while the Windows Search variant did not receive a fix at publication time.

This creates a patch management blind spot. Organizations that track only Microsoft CVEs may believe they fully addressed this class of NTLM leak after April’s Snipping Tool update, even though the Windows Search behavior remains separately reported.

Mitigations for Windows admins

The highest-value control is to block unnecessary outbound SMB traffic. Microsoft’s SMB security guidance recommends blocking outbound TCP port 445 to the internet at the corporate firewall because most environments do not need direct outbound SMB to the public internet.

Huntress also recommends blocking outbound SMB on TCP 445 and TCP 139 for hosts that do not need it. This reduces exposure not only to this Windows Search issue, but also to related NTLM leakage techniques that depend on outbound SMB authentication.

• Block outbound SMB traffic to the internet where business use does not require it.
• Audit and restrict outgoing NTLM traffic before enforcing hard blocks.
• Enable SMB signing to reduce the value of captured hashes in relay attacks.
• Monitor email and proxy logs for search: and search-ms: URI usage.
• Educate users that unusual Windows search links in emails or chats can carry risk.
• Review systems that still rely heavily on NTLM authentication.

Microsoft also provides a policy for restricting outgoing NTLM traffic. The policy can audit or deny outgoing NTLM requests from Windows clients, but Microsoft warns that administrators should audit first because blocking NTLM can affect older applications and services.

Mitigation	Why it helps	Deployment note
Block outbound SMB	Prevents Windows from sending SMB authentication to attacker-controlled internet hosts	Allow only required file servers, domain controllers, or approved cloud services
Audit outgoing NTLM	Shows which systems still send NTLM authentication requests	Review logs before switching to deny mode
Enforce SMB signing	Reduces NTLM relay risk	Test compatibility before wide deployment
Detect search: and search-ms: links	Flags suspicious protocol handler use in mail and web traffic	Add both schemes to security monitoring rules

What users should know

For home users, the main takeaway is simple: do not click unexpected Windows search links in emails, chat apps, browser pages, or documents. A suspicious link does not need to download a file to create risk.

Users should also keep Windows updated, although this specific Windows Search variant has not been patched according to Huntress. Security updates still matter because Microsoft patched the related Snipping Tool issue and may address similar behavior in future updates.

Businesses should treat this as part of the broader NTLM exposure problem. Microsoft’s SMB traffic guidance and its NTLM restriction policy give administrators practical ways to reduce the chance that a clicked link can leak useful authentication material.

The broader pattern deserves attention. Trellix showed in 2023 that Windows Search protocol handlers can support convincing phishing chains, while Varonis research showed that NTLMv2 leakage can appear across several Microsoft workflows. Huntress now argues that the same risk class still exists in Windows Search without a CVE-backed patch.

FAQ