CVE-2026-107615 in TightVNC
Summary
by MITRE • 10/08/2026
An uncontrolled search path element vulnerability in GlavSoft TightVNC Server for Windows before 2.8.88 allows a local authenticated user to execute arbitrary code with SYSTEM privileges. DynamicLibrary::init() (and ThemeLib) load screenhooks32.dll / screenhooks64.dll with LoadLibrary() using a bare file name and no LOAD_LIBRARY_SEARCH_* flags, so the TightVNC service follows the default DLL search order and loads an attacker-planted DLL from a writable directory earlier in that order (for example, an installation directory with permissive ACLs).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified as CWE-427 represents a critical uncontrolled search path element flaw within GlavSoft TightVNC Server for Windows versions prior to 2.8.88. This specific weakness arises from the improper handling of dynamic library loading mechanisms, where the application fails to specify explicit paths or security flags when invoking system functions responsible for locating and loading shared libraries. In this instance, the vulnerability is rooted in the DynamicLibrary::init() function as well as related components like ThemeLib, which are tasked with initializing graphical hooks necessary for screen capture functionality. These modules invoke LoadLibrary() using bare file names such as screenhooks32.dll or screenhooks64.dll rather than fully qualified paths. By omitting critical flags from the LOAD_LIBRARY_SEARCH_* family, the application defaults to the standard Windows DLL search order, which prioritizes directories based on system configuration and user permissions rather than security constraints.
From an operational perspective, this architectural oversight allows a local authenticated attacker to exploit the predictable nature of the default search path. When LoadLibrary is called without explicit directory specifications or secure loading flags, the operating system searches for the target DLL in several locations before checking the application's installation directory. If any preceding location in this search order possesses writable permissions accessible to the user, an adversary can place a maliciously crafted DLL with the same filename as the expected legitimate library into that directory. Upon execution of the vulnerable function, the TightVNC service will load the attacker-controlled DLL instead of the genuine system file. This substitution enables the injection and subsequent execution of arbitrary code within the context of the running process.
The impact of this vulnerability is severe due to the elevated privileges under which the TightVNC service typically operates. Since remote desktop services often run with SYSTEM-level privileges to ensure full access to screen resources and input devices, successfully exploiting this flaw grants an attacker complete control over the host system. The adversary can execute commands, install backdoors, exfiltrate sensitive data, or pivot further into the network without restriction. This scenario aligns closely with ATT&CK technique T1574.002, which describes Hijacking Executable Load Process via DLL Search Order Hijacking. It also relates to MITRE CWE-94 regarding improper control of generation of code (Code Injection), as the attacker effectively injects malicious logic into a trusted process through library substitution.
Mitigation strategies must focus on eliminating reliance on default search behaviors and enforcing strict path validation. The most effective remediation is for developers to update GlavSoft TightVNC Server to version 2.8.88 or later, where this loading mechanism has been corrected to use secure flags such as LOAD_LIBRARY_SEARCH_APPLICATION_DIR or similar variants that restrict the search scope to known safe locations. For organizations unable to immediately patch, administrative controls should be implemented to ensure that directories preceding the application installation path in the system PATH environment variable do not have writable permissions for standard users. Additionally, enforcing strict Access Control Lists on all directories involved in DLL loading can prevent attackers from planting malicious libraries. Regular auditing of service account privileges and minimizing the scope of SYSTEM-level services where possible further reduces the blast radius should such a vulnerability be exploited in other contexts.