Back to rankings

Claude Code Closes a Windows NTLM Credential-Leak Path

Claude CodeView original changelog

Claude Code 2.1.233 closes a Windows-specific path-validation gap that could leak NTLM credentials. Anthropic found that file paths written with the NT ??\ device prefix slipped past the tool's UNC path validation, meaning a crafted path could reach a remote share without triggering the permission checks meant to catch it. Because Windows automatically attempts NTLM authentication the moment a UNC-style path is touched, an attacker-controlled path could have coaxed a victim's machine into leaking its NTLM hash to a remote server. The fix brings the ??\ prefix spelling under the same validation as ordinary UNC paths.

Key Takeaways

  • A Windows-only path-spelling trick bypassed permission checks, letting a crafted \??\ NT device path skip the UNC path validation Claude Code normally applies.
  • The bug enabled silent NTLM credential leakage, because Windows auto-authenticates against UNC-style paths the moment they are touched, with no user-visible prompt.
  • No unusual interaction was required to trigger it, so a crafted path embedded in a repo or prompt could reach an attacker's server as a side effect of ordinary-looking file access.
  • Anthropic shipped the fix in Claude Code 2.1.233, released August 14, 2026, bundled with several other Windows-focused fixes in the same release.
  • This is a trust-boundary bug, not routine polish, since it let the agent reach network resources beyond what a user had explicitly authorized.
  • Windows users on pre-2.1.233 builds remain exposed, so updating is the only real mitigation; there is no user-side workaround beyond avoiding untrusted repositories.

What Was Broken

On Windows, Claude Code validates file paths before allowing tool calls to touch a UNC (Universal Naming Convention) network share, since those paths can trigger network authentication just by being referenced. Windows also accepts an alternate spelling of the same kind of location: the NT native namespace prefix \??\, historically used by device drivers and low-level system APIs. Claude Code's validator recognized the ordinary \\server\share spelling but not the \??\ prefix, so a path written that way sailed through as if it were an ordinary local file.

Why an NTLM Leak Follows

Windows resolves any UNC-style path, however it is spelled, by attempting to connect to the named host, and that connection attempt sends the current user's NTLM credentials for authentication. That behavior fires automatically, before any file actually opens, and it doesn't ask permission. A tool call that referenced a \??\-prefixed path pointing at an attacker-controlled server could therefore have caused a victim's NTLM hash to be sent off-machine as a side effect of Claude Code doing what looked like ordinary file access; nothing in the interface would flag it as unusual.

The Fix

Claude Code 2.1.233 folds the \??\ device-prefix spelling into the same UNC validation path already applied to \\server\share and //server/share forms. A path using that prefix to reach a remote location now requires the same permission approval as any other network path, closing the gap.

Who Should Care

This shipped alongside a broader batch of Windows-specific fixes in the same release, but it stands apart because it crosses Claude Code's trust boundary: it is exactly the kind of bug where the agent could reach further than a user explicitly approved. Windows users should update to 2.1.233 or later; no workaround exists on earlier builds beyond avoiding untrusted repositories and prompts that might embed such a path.