CVE-2026-44040: UltraVNC Weak Authentication Challenge RNG Vulnerability

Technical summary

The vncRandomBytes() function in rfb/vncauth.c (lines 119–129) seeds the C library rand() function using a combination of time(0), getpid(), and an initial rand() call. This produces a seed space of approximately 31 bits derived entirely from wall-clock time and process ID—both observable by an attacker monitoring the network or target system. The resulting 16-byte challenge can be enumerated within seconds, allowing an attacker to precompute or offline brute-force the VNC authentication response. On Windows platforms, the code may conditionally use vncEncryptBytes2.cpp, which calls CryptGenRandom (a cryptographically strong source); however, the actual code path in production binaries requires verification through compile-graph analysis and is currently under investigation.

Business impact

An attacker with network visibility to a VNC session can compromise the confidentiality and integrity of that session by forging authentication. This is particularly concerning for remote administration scenarios, where VNC is often used to manage sensitive infrastructure. An attacker need not interact with the server in real-time; they can observe a single authentication exchange and then crack it offline, enabling unauthorized access hours or days later. If VNC is exposed on a network perimeter or used over untrusted networks, this significantly lowers the barrier to unauthorized system access.

Affected systems

UltraVNC through version 1.8.2.2 is affected. The vulnerability is present in the rfb/vncauth.c code path, which is the default authentication mechanism on non-Windows platforms. On Windows, the shipped binaries may partially mitigate the issue if they use CryptGenRandom; however, this requires verification and should not be assumed without vendor confirmation. Any deployment of UltraVNC for remote administration should be evaluated for exposure, especially if the VNC service is accessible from untrusted networks.

Exploitability

Exploitability is constrained by the need to observe the authentication exchange in transit or on the target network. An attacker must passively capture or actively intercept the VNC protocol traffic to see the challenge bytes. Once captured, brute-forcing the seed takes only seconds due to the 31-bit seed space. No user interaction or special privileges are required; the attack is entirely passive from the user's perspective. The CVSS score of 4.8 (MEDIUM) reflects that this requires some precondition (network access) and results in partial confidentiality and integrity loss rather than complete system compromise.

Remediation

Upgrade UltraVNC to a version newer than 1.8.2.2 that uses a cryptographically strong random number generator (such as system-provided or OpenSSL entropy sources) for authentication challenge generation. Until patching is possible, restrict VNC access to trusted networks only, use a VPN or firewall rules to limit exposure, and consider disabling VNC on systems that do not require it. If legacy VNC is mandatory, layering SSH tunneling or other encrypted transport over the VNC connection provides defense-in-depth, though it does not remediate the weak RNG issue.

Patch guidance

Check with the UltraVNC project for releases after 1.8.2.2. Verify that the patched version documents the use of a cryptographically strong source for random number generation in the authentication challenge. Test patches in a non-production environment before deployment, and confirm that both the primary code path and any conditional branches (especially on Windows) are properly fixed. Review the vendor advisory for any breaking changes or configuration updates required by the patched version.

Detection guidance

Monitor network traffic for repeated or suspicious VNC authentication attempts from the same source IP within a short time window, which may indicate offline brute-forcing of a captured challenge. Log successful and failed VNC authentication events with timestamps and source IPs. If packet capture is available, inspect VNC protocol handshakes for patterns consistent with challenge reuse or rapid re-authentication. Note that passive detection of this vulnerability is difficult because the attacker does not require repeated server interaction; focus on access control and network segmentation to prevent the attacker from observing the authentication exchange in the first place.

Why prioritize this

Although the CVSS score is MEDIUM (4.8), the practical exploitability in air-gapped or internal network settings is higher. VNC is often used to manage critical infrastructure, and the ability to forge authentication offline poses a significant risk if the service is exposed or accessible without network segmentation. Organizations with VNC deployments on publicly routable networks or untrusted segments should prioritize this remediation. However, organizations that run VNC exclusively on isolated internal networks with strict access controls may deprioritize relative to high-severity vulnerabilities.

Risk score, explained

The CVSS 3.1 score of 4.8 reflects: Attack Vector Network (AV:N) because the vulnerability is exploitable remotely; Attack Complexity High (AC:H) because the attacker must observe the authentication exchange; Privileges Required None (PR:N) since no authentication is required before the attack; User Interaction None (UI:N) since no user action triggers exploitation; Confidentiality Impact Low (C:L) and Integrity Impact Low (I:L) because the attacker gains partial access to the VNC session; Availability Impact None (A:N) because the attack does not degrade system availability. The MEDIUM severity appropriately represents a threat to remote administration security without system-wide compromise.

Frequently asked questions