GV-ASManager EUVD-2026-52639

Exploitation requires the attacker to hold a local account with write access to at least one directory that GV-ASManager searches for DLLs before reaching the legitimate library location - candidates include the application's working directory, its installation directory if permissions are misconfigured, or any user-writable entry present in the Windows system PATH. The CVSS UI:R metric confirms that a separate user action - specifically, launching or restarting GV-ASManager - must occur after the malicious DLL is staged; the attack is not fully autonomous. The flaw is Windows-platform specific and limited to systems running GV-ASManager. Exploitation is blocked on systems where only administrators have write access to all directories in the DLL search path, and on systems where GV-ASManager is launched exclusively by accounts that cannot be influenced by lower-privileged users.

The CVSS 3.1 score of 7.3 (High) with vector AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H reflects a locally exploitable flaw requiring low privileges and a user interaction trigger, but delivering full confidentiality, integrity, and availability compromise. The local attack vector and required user interaction are meaningful constraints - an attacker must already possess a local account, write access to a directory in the DLL search path, and must wait for a privileged user to launch the application. EPSS data was not provided in the source intelligence, preventing a probabilistic exploitation estimate. The vulnerability is not listed in CISA KEV and no public proof-of-concept is known at time of analysis, which lowers operational urgency compared to remotely exploitable or actively exploited flaws. However, in physical security deployments where GV-ASManager may run on shared workstations or under accounts accessible to multiple staff members, the prerequisites may be more easily satisfied than in tightly controlled enterprise environments. The high CIA impact scores reflect realistic total process takeover once the malicious DLL is loaded.

A local user account with write access to a directory on GV-ASManager's DLL search path - such as a shared application folder or a user-writable PATH entry - places a crafted DLL named to match a library the application imports. When a system administrator or another user later launches or restarts GV-ASManager, Windows resolves the library name and loads the malicious DLL first, executing the attacker's code under the process's security context and potentially providing elevated system access or credential harvesting capability. No public proof-of-concept has been identified, but the technique is well-documented and requires no specialized tooling beyond a compiled DLL payload.