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

Clash Verge Rev advisory GHSA-99qg-xv7m-jf4v describes a local privilege-escalation risk in its Windows system service: a low-privilege local user or process may bypass service access restrictions and cause the service, which runs as LocalSystem, to execute code. The advisory explicitly says this is a local risk and cannot be exploited directly over the network.

The advisory lists <= 2.5.4 as affected and explicitly identifies v2.5.4+autobuild.0908.bbab52d as a patched build. Do not omit the +autobuild suffix: ordinary v2.5.4 and that patched build cannot be treated as having the same security status based on their main version number alone.

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.

A lack of pop-ups, working proxy traffic, or no observed suspicious processes does not rule out an old service still running. Conversely, having installed an affected version does not prove a device was exploited. Check whether the service exists and is running before deciding whether to disable it, update it, or treat the situation as a security incident.

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.

Record the current app version, operating mode, and whether TUN and the system proxy are enabled before uninstalling. Service operations generally require administrator approval. On a work or school device, ask an authorized administrator to do this; do not work around permission prompts 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.

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.

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.

Scan with Windows or an organization-approved security tool, and ask an administrator to inspect persistence mechanisms and privileged activity. If subscription tokens, node passwords, browser sessions, or cloud credentials may have been exposed, revoke and reissue them from another trusted device. If system integrity cannot be established, rebuild from trusted installation media and restore only verified-clean configuration.

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.

The Clash Verge Rev project documentation says the privileged service is a background process separate from the graphical app. For each future update, record the app's full build string, whether the service is installed, its actual executable path, whether TUN is enabled, and the relevant official Release or security advisory. The main version alone cannot distinguish ordinary v2.5.4 from the build explicitly identified as patched in the advisory.

The GHSA defines the affected range and a specific patched build for this local Windows privilege-escalation issue. The v2.5.5 Release supplies a newer version and service-related changes, but its release notes do not directly reference this GHSA. These sources answer different questions; do not turn a newer installation into a claim that the advisory has been verified.

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.