CVE-2026-97350 in SSL VPN Client
Summary
by MITRE • 11/03/2026
Securepoint SSL VPN Client v2 on Windows contains vulnerabilities in the handling of OpenVPN configurations and proxy settings that allow non-privileged local users to influence operations performed with NT AUTHORITY\SYSTEM privileges.
Two attack vectors have been identified:
*
Improper authorization of configuration checksum updates: The privileged service does not properly validate the authorization of connecting clients when updating the checksum of an OpenVPN configuration. This allows a non-privileged local user to modify an OpenVPN configuration and set a valid checksum without administrator privileges. The modified configuration is subsequently processed with NT AUTHORITY\SYSTEM privileges.
*
Argument injection via proxy settings: The client does not properly validate or sanitize proxy settings before passing them as arguments to OpenVPN. A non-privileged local user can inject additional arguments through the proxy settings, influencing the execution of OpenVPN with NT AUTHORITY\SYSTEM privileges. This attack vector does not require direct communication with the privileged service or modification of the protected OpenVPN configuration.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The Securepoint SSL VPN Client version 2 for Windows presents a critical security deficiency rooted in improper privilege separation and insufficient input validation within its interaction with the underlying OpenVPN infrastructure. This vulnerability allows non-privileged local users to escalate their privileges by influencing operations that are executed under the context of NT AUTHORITY\SYSTEM, which represents the highest level of access on Microsoft Windows operating systems. The core issue lies in how the client application handles configuration updates and proxy settings, failing to enforce strict authorization checks or sanitize inputs before passing them to privileged components. This architectural flaw effectively bypasses standard security boundaries, enabling an attacker who has already gained local user access to execute arbitrary commands with system-level privileges without requiring authentication or direct interaction with a network-facing service interface.
The first attack vector involves the improper authorization of configuration checksum updates within the OpenVPN management process. The privileged service responsible for managing VPN connections is designed to validate the integrity of configuration files by checking their cryptographic hashes before applying them. However, this validation mechanism fails to verify whether the client initiating the update possesses administrative privileges or legitimate authority to modify these settings. Consequently, a non-privileged local user can craft and submit a modified OpenVPN configuration file along with a validly calculated checksum. Because the service trusts the integrity of the provided hash without verifying the source's authorization level, it accepts the malicious configuration and processes it using NT AUTHORITY\SYSTEM privileges. This allows the attacker to alter network routing rules, install persistent backdoors via script commands embedded in the configuration, or redirect traffic through controlled endpoints, all while operating under the guise of a trusted system process.
The second attack vector exploits argument injection vulnerabilities within the proxy settings handling mechanism. The client application fails to properly validate or sanitize user-supplied data related to proxy configurations before passing these values as command-line arguments to the OpenVPN executable. This lack of input sanitization creates an opportunity for command injection, where a non-privileged local user can inject additional shell commands or flags into the execution string used by OpenVPN. Unlike the first vector, this method does not require direct communication with a privileged service daemon nor does it necessitate modifying protected configuration files on disk. Instead, the attacker simply needs to manipulate proxy settings within the client interface, causing the system to execute arbitrary code under NT AUTHORITY\SYSTEM privileges during the next VPN connection attempt or reconnection event. This vector is particularly dangerous because it bypasses file-based integrity checks and relies solely on runtime argument parsing flaws.
From a classification perspective, these vulnerabilities align with CWE-269 Improper Privilege Management and CWE-78 OS Command Injection, reflecting both the failure to enforce access controls and the unsafe handling of external inputs that result in command execution. In terms of tactical mapping within the MITRE ATT&CK framework, this scenario illustrates techniques associated with Local Privilege Escalation (T1068) and potentially Defense Evasion through process manipulation if the injected commands are designed to hide malicious activity from security monitoring tools. The ability to execute code as SYSTEM significantly impacts the confidentiality, integrity, and availability of the host system, allowing attackers to install rootkits, dump credential hashes using tools like Mimikatz, or pivot into other network segments with elevated trust levels.
Mitigation strategies must focus on enforcing strict least-privilege principles and implementing robust input validation across all client-side components that interact with privileged services. Developers should ensure that any operation affecting system-wide configurations requires explicit administrative verification before execution, regardless of the integrity check passed by hash algorithms. Furthermore, proxy settings and other user-controllable inputs must be rigorously sanitized to prevent command injection, utilizing allow-listing approaches rather than relying on blacklist filters which are often bypassable through encoding or special character manipulation. For immediate risk reduction, administrators should restrict local administrative rights where possible, apply vendor-provided patches as soon as they become available, and monitor for unusual process creation events involving OpenVPN binaries that originate from non-standard user contexts.