TightVNC Server EUVD-2026-94979

Requires an existing local, authenticated session on a Windows host running TightVNC Server prior to 2.8.88, plus a directory that (a) sits earlier in the default DLL search order than the legitimate screenhooks32.dll/screenhooks64.dll location and (b) is writable by the attacker - the description specifically cites an installation directory left with permissive (weak) ACLs. Exploitation is limited by these factors: it cannot be performed remotely or unauthenticated, it fails if all search-order directories ahead of the real DLL are non-writable by the attacker, and it depends on the SYSTEM-level TightVNC service invoking the vulnerable LoadLibrary() path. There is no user-interaction requirement beyond triggering the service's DLL load.

This is a credible but not emergency-tier priority. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) is internally consistent with the description: a local, already-authenticated user (PR:L) exploits an uncontrolled DLL search path to gain full SYSTEM-level code execution (C:H/I:H/A:H), making this a local privilege-escalation issue rather than remote compromise. The AV:L rating agrees with the description's 'local authenticated user' language, so there is no network-vs-local conflict to resolve. No EPSS score was provided, so exploitation probability cannot be quantified. The CVE is NOT listed in CISA KEV and no public POC is referenced, so exploitation status is 'no public exploit identified at time of analysis.' SSVC-style reasoning: exploitation is not observed, the attack is not automatable (requires an existing local foothold and a writable directory in the search path), but technical impact is total (SYSTEM). Net: this is a genuine local EoP worth patching on standard cycles, not a high-CVSS-but-illusory issue, but it is gated behind prior local access and a permissive-ACL precondition, which lowers real-world urgency relative to a network-exploitable flaw.

A low-privileged but authenticated user on a Windows host running TightVNC Server places a malicious screenhooks32.dll or screenhooks64.dll in a writable directory that appears earlier in the default DLL search order than the legitimate location (for example, a TightVNC install directory left with permissive ACLs). When the TightVNC service (running as SYSTEM) next calls DynamicLibrary::init()/ThemeLib and LoadLibrary() resolves the bare DLL name, it loads the attacker's DLL and executes its code with SYSTEM privileges. No public exploit code is referenced, so this reflects the described mechanism rather than a confirmed in-the-wild technique.