Sökvägen som läcker Windows-inloggningen: NT-prefixet som gick förbi UNC-kontrollen

Vad som faktiskt ändrades

Raden i 2.1.233 lyder ordagrant: ”Fixed Windows paths spelled with the NT \??\ device prefix bypassing UNC path validation, closing an NTLM credential-leak vector”. Tre dagar senare, i 2.1.234, kommer uppföljningen: ”remote file reads, session restore, CLAUDE.md includes, workflow scripts and file uploads now reject Windows NT-namespace (\??\) paths, hardening the remaining pre-approval file accesses against the NTLM credential-leak vector”.

Det intressanta ligger i det sista ledet. Den första rättningen lagade kontrollen. Den andra gick igenom allt som läser en fil innan godkännandet: sessionsåterställning, inkluderade kontextfiler, arbetsflödesskript och uppladdningar. Källan säger ingenting om svårighetsgrad, spridning eller om felet utnyttjats, och den här texten påstår därför ingenting om det heller. Det som går att lära av den är felklassen, och den är inte verktygsspecifik.

Samma fil, flera stavningar

Windows har mer än ett sätt att skriva samma resurs. Microsofts dokumentation räknar upp traditionella DOS-sökvägar (C:\Test\Foo.txt), UNC-sökvägar (\\Server\Share\Test\Foo.txt) och DOS-enhetssökvägar med prefixen \\.\ och \\?\. Och där finns det som gör en teckenjämförelse otillräcklig: enhetsnamnrymden har en egen länk för UNC. Dokumentationen skriver ut den rakt av — ”There is a specific link for UNCs that is called, not surprisingly, UNC” — med exemplen \\?\UNC\Server\Share\Test\Foo.txt och \\.\UNC\Server\Share\Test\Foo.txt.

Under Win32-lagret finns dessutom NT-namnrymden, där filer har objektnamn relativa till \DosDevices: filen C:\Directory\File kan enligt drivrutinsdokumentationen anges som \DosDevices\C:\Directory\File. Prefixet \??\ är stavningen som pekar in i just den namnrymden. Termen ”NT-namnrymd” om \??\ är changelogens egen; Microsoft Learn dokumenterar \\?\, \\.\, \DosDevices och GLOBALROOT, men jag hittade ingen Learn-sida som ordagrant förklarar \??\. Poängen står ändå: ett värdnamn kan nås utan att strängen börjar med två omvända snedstreck.

Ett steg till: \\?\ är inte bara en annan stavning, utan ett uttryckligt avstängningskommando. Dokumentationen är tydlig — prefixet ”tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system”. Normalisering är alltså inte något som alltid händer under dig. Den är något du kan råka stänga av genom att skicka vidare en sträng du inte tittat på.

Läckan är uppkopplingen, inte filen

Varför spelar det roll att en sökväg pekar bort från maskinen? För att Windows autentiserar när den ansluter. Microsofts egen beskrivning av varför man blockerar NTLM på SMB-klienten säger det rakt ut: blockeringen ”prevents bad actors from tricking clients into sending NTLM requests to malicious servers, counteracting brute force, cracking, and pass-the-hash attacks”.

På operativsystemsnivå finns en motåtgärd, men den täcker inte alla. SMB-klientens NTLM-blockering kräver enligt Microsoft Windows 11 version 24H2 eller Windows Server 2025 eller senare, plus en SMB-server som tillåter Kerberos. Den slås på med Set-SmbClientConfiguration -BlockNTLM $true, eller via grupprincip under Computer Configuration → Administrative Templates → Network → Lanman Workstation och inställningen Block NTLM (LM, NTLM, NTLMv2). Det är ett bra lager att ha, och ett dåligt argument för att slippa validera: du styr inte vilken Windows-version dina användare kör.

Testfallet som avslöjar en strängbaserad kontroll

Det här är det snabbaste sättet att få veta om din egen validering normaliserar eller bara jämför tecken. Kör dina sökvägsformer genom valideringen och se vilken som slinker igenom. Siffrorna nedan är mätta på Node.js v24.13.0 under Windows 11 den 18 augusti 2026, utan nätverksanrop.

const p = require('node:path');
const s = '\\??\\UNC\\attacker.example\\share\\a.txt';

p.win32.isAbsolute(s)      // true
p.win32.normalize(s)       // '\??\UNC\attacker.example\share\a.txt'  (oförändrad)
p.win32.parse(s).root      // '\'   OBS: inte '\\attacker.example\share\'
p.win32.resolve(s)         // 'C:\??\UNC\attacker.example\share\a.txt'
s.startsWith('\\\\')       // false

Jämför med samma resurs skriven som \\?\UNC\attacker.example\share\a.txt: där blir parse().root lika med \\?\UNC\ och startsWith sant. Och skriver du den med snedstreck, //attacker.example/share/a.txt, är startsWith falskt på originalsträngen medan normalize gör om den till \\attacker.example\share\a.txt. Tre av de vanligaste hemmasnickrade kontrollerna — ”börjar med två omvända snedstreck”, ”roten börjar med två omvända snedstreck” och ”absolut men inte UNC” — svarar alltså lokal fil på minst en form som inte är det.

En viktig begränsning som är lika mätt som resten: Node:s egen fs når inte nätverket från \??\-strängen. fs.statSync('\\??\\C:\\Windows\\win.ini') ger ENOENT, eftersom sökvägen löses upp till C:\??\C:\Windows\win.ini, medan \\?\C:\Windows\win.ini öppnas utan problem. Risken ligger alltså inte i att körläget självt kopplar upp sig. Den ligger i att din kontroll säger ”säker lokal sökväg” och att originalsträngen sedan skickas vidare till något annat som löser upp den: ett skal, en barnprocess, ett annat verktyg, ett systemanrop längre ned.

Kontrollen som normaliserar först

Ordningen är hela poängen. Avvisa innan du löser upp, lös upp innan du jämför, och använd sedan det du löste upp.

Var kontrollen måste sitta

Listan i 2.1.234 är i praktiken en inventering över de ställen man glömmer: fjärrläsning, sessionsåterställning, inkluderade kontextfiler, arbetsflödesskript och filuppladdningar. Alla har en sak gemensamt — de rör en fil innan användaren har godkänt något. Bygger du ett verktyg med en godkännandedialog är det lätt att tro att dialogen är skyddet. Men koden som läser filen för att kunna visa dialogen, räkna ut en storlek eller bygga en förhandsvisning har redan gjort anropet. Ett godkännande som kommer efter anslutningen skyddar ingenting.

Samma changelog visar också priset för att ta i för mycket. I 2.1.232 skärptes Bash-kontrollen för symlänkar och för indataomdirigeringar (< file). I 2.1.233 rullades båda tillbaka, efter att automatläget börjat stanna för manuellt godkännande på helt vanliga kommandon av typen cd <katalog> && <kommando> > fil — beskrivet i källan som en regression — med beskedet att en smalare version kommer senare. Lärdomen är obekväm men användbar: en sökvägskontroll som ger falsklarm på vardagsarbete blir avstängd, och då skyddar den ingen. Gör regeln smal och exakt hellre än bred och irriterande.

Den här felklassen hör hemma bredvid två andra saker vi skrivit om. Promptinjektion i din egen app handlar om att text blir instruktioner; det här handlar om att en tillåten filoperation missbrukas genom hur argumentet stavas. Och där agentavgränsningen bestämmer vad verktyget får göra, bestämmer sökvägsvalideringen var det får göra det. Ingen av dem ersätter den andra. Ska du gå bredare på en färdig kodbas är säkerhetsgranskningen av en AI-byggd kodbas nästa steg.