CVE-2023-6631 is a high severity unquoted service path flaw in SUBNET PowerSYSTEM Center versions 2020 Update 16 and prior. An authorised local user may insert code into the service path and escalate privileges. The record names no fix, so read CISA advisory ICSA-23-353-01.
What's affected
- Product: SUBNET PowerSYSTEM Center.
- Affected: 2020 Update 16 and prior, per the record.
- Fixed version: not named in the record. See CISA ICSA-23-353-01 and contact SUBNET.
- Access needed: a local account with low privileges.
The record gives a CVSS 3.1 base score of 7.8 (high) with the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The CISA Known Exploited Vulnerabilities flag in the record is false. This post does not claim exploitation in the wild.
How to check if you're exposed
On the Windows host, list services whose path is unquoted and contains a space.
Get-CimInstance Win32_Service | Where-Object { $_.PathName -notmatch '^"' -and $_.PathName -match ' ' } | Select-Object Name,PathName
Look for any PowerSYSTEM Center service in the result, then check the folder permissions along that path. The command only lists services, it changes nothing.
What to do now
- Find PowerSYSTEM Center installations and their update level.
- Read CISA advisory ICSA-23-353-01 and ask SUBNET for the current fixed release.
- Correct the service path by quoting it, or apply the vendor update that does so, and restrict write access to each folder on the path.
- Limit who can log in to the host, since the flaw needs a local account.
- Run the free in-browser dependency scan at gold.safeguard.sh/scan on any project you build that bundles this component, and keep the result next to your inventory.
Why it matters
The record maps this issue to CWE-428 (Unquoted Search Path or Element): A Windows service path with spaces is not wrapped in quotes, so the system may start a different executable than the one intended if an attacker can place a file in the path.
An unquoted service path with spaces lets Windows try several candidate programs before it reaches the intended one. If a user can write a file to one of those earlier locations, the service may start it, with the privileges of the service account.
This is a local flaw, so the main risk is a shared or compromised host. These services often run as a powerful account, which is why the base score is 7.8. The fix on the host is cheap, since quoting the path and tightening folder permissions closes the trick.
Quick check
Is it exploitable remotely?
No. The vector is local and needs a low privileged account on the host.
Can I fix it without a vendor update?
Quoting the service path and locking down folder permissions addresses the class of issue, but follow the vendor guidance in the advisory.
Sources
These are the references listed in the NVD record for this CVE. They were not fetched when this post was written, so confirm fixed versions in the advisory before acting.
Last reviewed: 19 October 2026.
