Powershell Fix Unquoted Service Path

An unquoted service path is a Windows service launch command where the executable path contains spaces but is not wrapped in quotes. Use PowerShell to fix it only when the service binary path contains spaces and starts without quotes; check the exact ImagePath first, then quote only the executable path, not arguments. If you leave it as is, or quote the wrong part, you can trigger local privilege escalation or break a service by changing a valid command line. This guide shows how to triage false positives, confirm impact, and remediate safely with PowerShell.

The risk matters most for services that start automatically, especially when the service runs as LocalSystem or another privileged account. A path issue by itself is not enough; exploitability also depends on whether the folder or file is writable by a lower-privileged user.

What an unquoted service path means

Two common examples help separate exposure from noise. A service that points to svchost.exe -k often has spaces in its arguments, not in the executable path. A vendor updater or wrapper may also look odd at first glance, but still be safe if the executable boundary is quoted correctly.

Likely causes and false positives

The first thing to rank is real exposure versus harmless spacing. A path with no leading quotes and a space before the executable boundary deserves attention. A path that is already quoted, or one where the spaces live only in arguments, belongs lower on the list.

svchost.exe -k is the most common false positive pattern to exclude from naive checks. The executable path is usually safe, while the service arguments contain the spaces. Non-.exe launchers, wrappers, and vendor command lines need manual review because quoting the wrong segment can break them.

Suppose a service launches svchost.exe -k netsvcs. That line should not be treated the same way as C:\Program Files\App Folder\Service.exe -service with no quotes around the executable path. The second case can be vulnerable; the first is usually a parse problem only for unsophisticated filters.

A common first-timer mistake is to flag every line that contains a space. That produces noise, and it can hide the services that deserve permission review because someone spent time chasing harmless entries.

How do you find vulnerable services with PowerShell?

Audit Win32_Service first, because its PathName property exposes the service command line in a form you can triage quickly. Then cross-check StartMode and StartName to prioritize services that start automatically and run under privileged accounts. After that, confirm the registry ImagePath value under HKLM:\SYSTEM\CurrentControlSet\Services. (Microsoft Learn)

The registry hive is a useful cross-check because it contains more than service entries alone, including drivers. That means it is broader than Win32_Service, so it can confirm the launch string even when the service class view omits related entries. For remediation, ImagePath is the value you usually correct.

In one PowerShell scan, 317 services produced zero unquoted paths, while a naive space-only filter flagged 230 services and 227 of those were svchost.exe entries. A registry cross-check found 798 keys with an ImagePath and zero unquoted .exe paths. The lesson is simple: a space-only filter is too blunt.

Service path triage table

How do I tell if a service path is actually vulnerable and not a false positive?

Check three things together: whether the path starts with quotes, where the .exe boundary falls, and whether the spaces are inside the executable portion rather than in arguments. If the path is already quoted, or the spaces live only after the executable, it is usually not a candidate.

Then verify whether the service runs as LocalSystem or another high-privilege account, and whether a standard user can write to the target folder or an upstream folder in the path. That permission check is what separates a theoretical issue from a practical one.

Say your service path is C:\Program Files\Vendor\Agent\agent.exe -svc. That can be a real candidate if the executable path is not quoted. Suppose the same service launches "C:\Program Files\Vendor\Agent\agent.exe" -svc. That one is already quoted correctly.

How do I fix it safely?

Quote only the executable portion of ImagePath, then leave every argument, switch, and wrapper parameter exactly where it belongs. The safest fix is small and exact. If the path is a launcher or wrapper, do not move the quotes around the full command line unless the vendor syntax requires that layout.

Services running as LocalSystem deserve extra care because the impact of a writable path is much higher. A service that starts under a less-privileged account may still need a fix, but the exploitability threshold is different. Permissions on the folder and the binary matter as much as the string itself.

1. Open services.msc and note the service name, startup type, and logon account.
2. Run Get-CimInstance Win32_Service | Select-Object Name, StartMode, StartName, PathName and identify any service whose PathName starts without quotes and has spaces in the executable path.
3. Check the registry value at HKLM:\SYSTEM\CurrentControlSet\Services\<ServiceName>\ImagePath and copy the current value to a text file before making changes.
4. Edit only the executable path so it becomes quoted, such as "C:\Program Files\App\Service.exe" -arg1 -arg2, then save the updated ImagePath.
5. Restart the service in services.msc or with Restart-Service, then verify it starts cleanly and compare the updated command line with the saved original.

Include UninstallString in related cleanup work when the installer path has the same quoting problem. That value is separate from the service fix, but it can carry the same path parsing issue during software removal or repair workflows.

Related remediation guidance also appears in contexts tied to CVE-2013-1609, CVE-2014-0759, and CVE-2014-5455. Treat those names as guidance context, not as proof that a live exploit exists in every case.

Should you edit the registry or deploy a script for one service or many?

Use a direct registry edit when you are fixing one known service and can validate the service name, ImagePath, and restart impact by hand. Use a remediation script when you need repeatability, logging, or a controlled rollout across many endpoints. The safer choice depends on scale, change control, and rollback needs.

A script is usually better when the same quoting pattern appears across multiple devices, because it can detect, repair, and report in a consistent way. A manual edit is better when a vendor wrapper is involved and the launch string needs human review before the change lands.

1. Build a detection script that reads Win32_Service.PathName and flags only service paths where the executable portion starts without quotes and contains spaces.
2. Build a remediation script that rewrites the corresponding ImagePath with quotes around the executable only, leaving arguments unchanged.
3. Test both scripts against a small set of nonproduction services before broad deployment.
4. Capture the before-and-after command line in your logs so you can confirm exactly what changed.
5. Keep a rollback copy of the original ImagePath value before you update it.

Intune Proactive Remediation can deploy this pattern with a detection script and a remediation script, but it requires supported enterprise licensing. The tradeoff is rollout control: you gain consistency, but you also need change windows, assignment scoping, and rollback planning. (Microsoft Learn)

Prevention: when you deploy new software, check the service command line before you approve it, especially for services that run as LocalSystem or install into Program Files paths.

Frequently asked questions

How to fix the windows unquoted service path vulnerability powershell

Use PowerShell to inspect PathName, StartMode, and StartName, then update HKLM:\SYSTEM\CurrentControlSet\Services\<name>\ImagePath only when the executable path is unquoted and contains spaces. After editing, run Restart-Service <name> or restart the host during a maintenance window.

How do I find unquoted service paths with PowerShell?

Start with Get-CimInstance Win32_Service | Select-Object Name, StartMode, StartName, PathName. Then review the registry under HKLM:\SYSTEM\CurrentControlSet\Services for cross-checking. A path that is already quoted or that only places spaces in arguments should drop out during triage.

How do I fix an unquoted service path without breaking the service?

Quote only the executable path in ImagePath and leave parameters in place. If the command line uses a wrapper, updater, or vendor launcher, confirm the vendor’s expected syntax before editing. After the change, restart the service and verify that it starts without an event log error.

Can I deploy an unquoted service path fix through Intune?

Yes. Use Intune Proactive Remediation with a detection script that finds unquoted executable paths and a remediation script that rewrites ImagePath. Keep in mind that this feature needs supported enterprise licensing, and you still need a rollback plan for services that fail after the quote change.