How should you handle the Clash Verge Rev Windows service privilege-escalation risk?

The Clash Verge Rev advisory GHSA-99qg-xv7m-jf4v concerns the Windows system service. A local low-privilege user or process may bypass access restrictions and make the service execute code under the highly privileged LocalSystem account. It cannot be directly exploited remotely over the network.

Check the full build against the advisory: the affected range is <= 2.5.4, and the explicit fixed build is v2.5.4+autobuild.0908.bbab52d. The +autobuild suffix must not be omitted; ordinary v2.5.4 cannot be treated as having the fixed build’s security status merely because the main version matches.

The affected component is the system service installed by Clash Verge Rev on Windows, not Mihomo rules, subscriptions, or proxy nodes. Do not apply this advisory to macOS, Linux, or other Clash clients. The system service runs separately from the graphical app and may remain in the background after you exit Clash Verge Rev, so closing its window or switching off TUN does not prove the service has stopped.

If this Windows computer has had the Clash Verge Rev service installed and you cannot confirm that the running build is the one identified as patched in the advisory, switch off TUN first, then disable or uninstall the system service.

The project's own settings offer an Uninstall Service action. Its documentation also says that on Windows you can use the delete icon next to the virtual network adapter in Settings. The location may differ by version, so follow the labels shown by your installed build.

Service operations usually require administrator authorization. On work or school devices, an authorized administrator should perform them. Do not bypass authorization by changing system-directory permissions.

The project documentation says that closing the graphical app does not automatically stop the service process. After uninstalling, restart the computer and confirm in the Windows Services console that the relevant Clash Verge Rev service has not restarted. Do not stop unrelated network services with similar names. If you cannot identify the service or uninstalling fails, stop using the device for sensitive work and ask an administrator to check its installation path.

Record the complete string shown in Clash Verge Rev's About or version screen; do not copy only the leading 2.5.4. When comparing it with the GHSA's patched build, the main version, +autobuild suffix, and trailing identifier must all match. If the app shows only a shortened version, keep the service off until you have enough information.

In the Windows Services console, check whether the service exists and is running. Verify that its executable path points to the current Clash Verge Rev installation. The project describes the service as a separate process, so an updated or closed graphical app does not prove that an old component has gone away. Do not connect to the service's local communication interface or send test requests just to read its version.

No pop-up, or a working proxy, does not rule out an old service still running. Check the service manager and actual file path instead of waiting for symptoms.

The official Clash Verge Rev v2.5.5 Release lists several fixes for service installation, operation, and compatibility, but does not explicitly name GHSA-99qg-xv7m-jf4v as a fixed item. Being a newer stable v2.5.5 alone cannot replace the precise patch evidence in the advisory. If maintainers later publish an updated range of patched versions, use their new official guidance.

If upstream later updates the GHSA's patched-version range or publishes dedicated service-security guidance, reassess using that new first-party evidence. For managed computers, have an administrator approve service updates and periodically confirm that the removed old service has not been installed again.

Use v2.5.4+autobuild.0908.bbab52d, the build currently listed in the GHSA, as the explicitly verifiable patched target. Obtain installers only through the official clash-verge-rev/clash-verge-rev project channel, and check the full filename, system architecture, and any checksum information on the release page.

If no official asset for that build can be verified, leave the old service uninstalled and wait for maintainers to provide an independently verifiable update. Do not use search ads, file-sharing drives, or third-party repackaged installers.

The official v2.5.5 Release is a place to find newer installers, but its release notes do not directly say that it fixes this GHSA. If you choose v2.5.5 or a later stable release, separately verify the maintainer's advisory, the service component, or whether the fixing commit is included. Do not re-enable a privileged service until that evidence is available.

Before installing, back up trusted Profiles and app settings, and keep a record of the original installer's source and version. After upgrading the app, follow the project's official steps to deal with the old service and install the new one. Finally, check which component the service is actually running; an Update Complete message is not enough. Never copy a service executable from an old backup into the system directory.

If you choose not to use the service for now, confirm after a restart that it is not running and TUN remains off. Make a real HTTPS request using a connection method that does not depend on the service. A working proxy shows that connectivity is restored, but does not replace checking service status.

If you have installed the exact build identified as patched in the advisory, check the full build string, current service executable path, service-mode state, and a real connection. If you need TUN, test TUN traffic separately; if you do not need TUN, there is no reason to reinstall the service just for a test.

Do not run vulnerability-reproduction scripts, create a test low-privilege account, or let an unknown website access local interfaces. Version, source, service status, and an ordinary work request are enough for a user-side update check. Determining whether an intrusion occurred requires separate system evidence.

An affected version with a running service indicates an exposure condition, not proof that someone obtained SYSTEM privileges. If you also find an unknown high-privilege process, a security alert, an unusual scheduled task, altered credentials, or other timestamped anomalies, treat it as a possible device compromise.

First isolate the device from the network and stop using the old service. Record the full version, service path, when the anomaly began, alerts, and suspicious processes. Preserve original logs and configuration, and share only redacted copies. Do not immediately delete unfamiliar files in an attempt to clean up; they may be evidence needed to assess impact.

Run a scan with security tools provided by Windows or approved by your organization, and have an administrator check startup entries, scheduled tasks, and other items that may keep running, along with privileged activity. If subscription token values, node passwords, browser sessions, or cloud credentials may have been exposed, invalidate the old credentials and issue replacements from another trusted device. If system integrity cannot be confirmed, rebuild from trusted installation media and restore only configurations confirmed to be clean.

If the patched build cannot be installed on this device, the service fails to start, or TUN does not work, keep the old service off. Restore essential connectivity through a non-service mode of Clash Verge Rev and the system proxy, or switch to another client with a verified source. The system proxy does not cover every app, so test the actual work you need to do.

If connectivity still fails, first check that the system proxy points to a local port that is still listening. Then check the current Profile and node. Do not copy service files from an old backup, downgrade to an affected build, or loosen service-directory permissions just to restore TUN.

When reporting upgrade trouble to the project, include the system version, CPU architecture, full app build string, service status, first error, and redacted logs. If the only newer installer available lacks explicit GHSA patch evidence, leave its privileged service uninstalled and wait for maintainers to clarify.