CVE-2026-4962: 
UltraVNC vulnerability analysis and mitigation

CVE-2026-4962 is an uncontrolled search path vulnerability in UltraVNC affecting versions 1.6.0.0 through 1.6.4.0. The flaw resides in the version.dll library within the UltraVNC Service component, where improper handling of the DLL search path can be manipulated by a local attacker. It was publicly disclosed on March 27, 2026, and assigned by VulDB; the vendor was contacted prior to disclosure but did not respond. The vulnerability carries a CVSS v3.1 base score of 7.0 (High) and a CVSS v4.0 base score of 6.4 (Medium) (VulDB, Red Hat CVE).

The root cause is classified under CWE-426 (Untrusted Search Path) and CWE-427 (Uncontrolled Search Path Element). When the UltraVNC Service loads version.dll, it does not enforce a trusted, absolute path, allowing an attacker to place a malicious DLL in a directory that is searched before the legitimate one — a technique known as DLL Search Order Hijacking (MITRE ATT&CK T1574.001). Exploitation requires local access and low privileges, but is characterized as high complexity, meaning specific conditions or race conditions must be met. A proof-of-concept has been publicly released via a Google Drive link referenced in the VulDB submission (VulDB, VulDB Submission).

Successful exploitation allows a local attacker with standard (low) privileges to execute arbitrary code in the context of the UltraVNC Service, which typically runs with elevated system privileges. This results in complete compromise of confidentiality, integrity, and availability of the affected system. The attack does not require user interaction, and if the service runs as SYSTEM, the attacker can achieve full local privilege escalation (VulDB, Red Hat CVE).

A proof-of-concept exploit has been publicly released and is referenced via a Google Drive file linked in the VulDB submission, though Feedly's analysis classified the submitted URL as an advisory rather than a functional exploit. The EPSS score is extremely low at 0.000050, indicating minimal probability of widespread exploitation in the near term. There is no evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog as of the time of this report (VulDB, VulDB Submission).

1. Reconnaissance: Identify systems running UltraVNC versions 1.6.0.0–1.6.4.0 with the UltraVNC Service active. Confirm the service is running and identify the directories included in the DLL search path.
2. Identify writable directory: Determine a directory in the DLL search order (e.g., the application directory, current working directory, or a PATH-listed directory) that the attacker's low-privileged account can write to and that is searched before the legitimate version.dll location.
3. Craft malicious DLL: Create a malicious version.dll that exports the same functions as the legitimate Windows version.dll (e.g., GetFileVersionInfoA, VerQueryValueA) while also executing attacker-controlled code (e.g., adding a backdoor user or launching a reverse shell).
4. Place the malicious DLL: Copy the crafted version.dll into the identified writable directory that precedes the legitimate path in the search order.
5. Trigger DLL load: Wait for or trigger a restart of the UltraVNC Service (e.g., via a system reboot or service restart if the attacker has sufficient rights). The service loads the malicious DLL instead of the legitimate one.
6. Achieve privilege escalation: The malicious code executes in the context of the UltraVNC Service (potentially SYSTEM), granting the attacker elevated privileges on the local machine (VulDB).

• File System: Presence of an unexpected version.dll in the UltraVNC installation directory or any directory listed in the system PATH ahead of %SystemRoot%\System32; file creation timestamps inconsistent with legitimate software installation.
• Process: Unusual child processes spawned by the UltraVNC Service process (e.g., cmd.exe, powershell.exe, net.exe) that are not part of normal VNC operation.
• Logs: Windows Event Log entries (Event ID 7045 or 7036) showing unexpected UltraVNC Service restarts; application event log entries indicating DLL load failures or unexpected module loads.
• Network: Unexpected outbound network connections originating from the UltraVNC Service process to external IP addresses, particularly on non-standard ports.

No vendor patch is currently available, as the UltraVNC vendor did not respond to the coordinated disclosure. As interim mitigations: restrict local user write access to the UltraVNC installation directory and all directories in the system PATH; apply the principle of least privilege to accounts on systems running UltraVNC; consider disabling or uninstalling UltraVNC if it is not operationally required; and monitor for suspicious DLL placement activity using endpoint detection tools. Organizations should watch for a vendor patch for versions beyond 1.6.4.0 and apply it promptly when available (VulDB, Red Hat CVE).

A blog post by Jericho (jericho.blog) published on March 31, 2026, referenced this CVE in the context of a broader complaint about CNA (CVE Numbering Authority) rules, suggesting some community frustration with how this disclosure was handled given the vendor's non-response. Red Hat tracked the CVE in their security advisory system. No major vendor statements, widespread media coverage, or significant social media discussion beyond automated CVE alert feeds has been observed (Jericho Blog, Red Hat CVE).