Unquoted Path Handling in Windows

When Windows encounters an unquoted file path containing spaces, it resolves the path by trying every possible truncation, from shortest to longest. This behavior exists across many Windows APIs that accept command lines — most importantly CreateProcess, and by extension the Service Control Manager when starting services whose ImagePath lacks surrounding quotes.

Resolution behavior

Given the unquoted path:

C:\Program Files\Application Path\App.exe

Windows searches for executables in this order:

  1. C:\Program.exe
  2. C:\Program Files\Application.exe
  3. C:\Program Files\Application Path\App.exe

If an executable is found at a shorter truncation point, the remainder of the string is passed to it as command-line arguments. The first match wins.

Security relevance

This is the root cause of the unquoted service path class of privilege escalation vulnerabilities (exploit-windows-services-unquoted-paths), tracked by MITRE ATT&CK as T1574.009 — Hijack Execution Flow: Path Interception by Unquoted Path. If an attacker can write an executable to any of the intermediate truncation points (e.g., C:\Program.exe or C:\MyPrograms\Disk.exe), a service or application launched via the unquoted path will execute the attacker’s binary instead of the intended one — often as SYSTEM.

Exploitability caveats

Not every unquoted path is exploitable. As Raymond Chen (Microsoft) notes, the attack requires write access to a directory along the truncation chain, and the standard locations (C:\, C:\Program Files\) are writable only by administrators by default. A genuinely exploitable case typically involves:

  • A directory created by third-party software with overly permissive ACLs (e.g., C:\MyPrograms\ writable by Everyone)
  • Paths rooted outside protected system directories
  • Combined misconfigurations (unquoted path + writable directory + auto-start service running as SYSTEM)

Quotation marks aren’t needed when the path contains no spaces — vulnerability scanners frequently flag C:\Windows\system32\svchost.exe -k xyz as “unquoted,” but the -k xyz portion is intended command-line arguments, not part of the path. Reports of unquoted-path vulnerabilities should be validated for actual writability of the truncation directories before being treated as real findings.

Cross-domain connections

  • vuca — VUCA’s “ambiguity” (indeterminacy about what a thing means) is exactly what unquoted-path resolution institutionalizes: a resolution rule where the first matching interpretation wins, and the attack exploits the gap between intended and actual referent
  • common-mode-failure — one shared parsing behavior in a platform API propagates to every CreateProcess/SCM consumer, so a single design decision produces system-wide correlated exposure — call-site diversity buys nothing
  • unix-set-path-session — the benign mirror of the same problem: PATH search order also answers “which binary does this name resolve to,” decided by list order — the unquoted-path truncation behavior is that ambiguity with a writable-directory twist

Sources

See also