CVE-2026-7830: UltraVNC MS-Logon II Weak Cryptography Credential Disclosure

Technical summary

The MS-Logon II authentication scheme in UltraVNC implements a Diffie-Hellman key exchange with inadequate parameters. The DH_MAX_BITS constant limits the prime modulus to fit within a 64-bit unsigned integer, making the key exchange vulnerable to Pollard's rho discrete logarithm algorithm, which can recover the shared secret in subsecond time on modern hardware. Additionally, the private exponent generation in rfb/dh.cpp relies on the rng() function, which seeds three concatenated libc rand() calls with time(NULL). This yields approximately 31 bits of effective entropy, allowing a passive network observer to brute-force the private exponent in under a minute. An attacker observing the MS-Logon II handshake can thus derive the shared DH key, decrypt the authentication payload, and obtain credentials in plaintext. The vulnerability is specific to the legacy MS-Logon II protocol; the newer MS-Logon III variant, which uses X25519 elliptic-curve cryptography and AES-256-GCM, is not affected.

Business impact

Organizations using UltraVNC for remote desktop access face credential compromise on every legacy MS-Logon II connection. An attacker with network visibility—whether internal, positioned on a compromised router, or controlling a compromised ISP segment—can passively harvest login credentials without triggering host-based alarms. This directly enables lateral movement, privilege escalation, and persistent access to critical infrastructure. For regulated industries (healthcare, finance, energy), credential theft from remote access tools often triggers breach notification obligations. The impact is amplified in environments where UltraVNC is the primary remote desktop solution or used for administrative access to sensitive systems.

Affected systems

UltraVNC through version 1.8.2.2 is affected when using the MS-Logon II authentication method. This includes all instances explicitly configured for or defaulting to MS-Logon II authentication. Verify your deployment: check the UltraVNC server and viewer configurations to confirm which authentication scheme is active. Administrators who have already migrated to MS-Logon III or other modern authentication (e.g., TLS-based schemes) are not impacted by this specific vulnerability, though they should still validate their configuration. Legacy installations, particularly those running older stable versions, are at highest risk.

Exploitability

This vulnerability requires network-level access to observe the MS-Logon II handshake—it cannot be exploited blindly. However, the attack is entirely passive once that network vantage point is achieved, making it detectable only through traffic analysis or endpoint logging. The computational cost is negligible on current hardware (under one second to break the DH exchange, under one minute to recover the session key). The attacker requires no prior authentication, no user interaction, and no exploitation of a service vulnerability; credential interception via cryptanalysis alone is sufficient. The CVSS score of 7.4 (HIGH) reflects the high confidentiality impact, though the AC:H (Attack Complexity High) rating accounts for the requirement to have network-level observation capability.

Remediation

Immediate mitigation: Disable MS-Logon II authentication on all UltraVNC deployments and migrate to MS-Logon III or another modern, authenticated encryption scheme (e.g., TLS with strong ciphers). Long-term: Upgrade UltraVNC to the latest version once a patch is released that removes or deprecates MS-Logon II. For organizations unable to upgrade immediately, implement network segmentation and VPN enforcement to ensure UltraVNC traffic is only accessible over encrypted, authenticated channels that provide cryptographic assurance independent of the VNC authentication method. Monitor and rotate credentials for any accounts that may have been used over unpatched UltraVNC connections during the vulnerability window.

Patch guidance

Watch the official UltraVNC project repository and security advisories for a patch that addresses the weak DH parameters and RNG seed mechanism. The vendor should deprecate MS-Logon II entirely or, at minimum, increase DH_MAX_BITS to at least 2048 bits and replace the seeded rand() calls with a cryptographically secure random number generator. Verify patch applicability against the vendor advisory before deployment. In the interim, configuration-based mitigation (enforcing MS-Logon III or disabling legacy authentication) is the preferred approach if available in your UltraVNC build.

Detection guidance

Network detection: Inspect encrypted UltraVNC traffic for MS-Logon II handshake patterns (observable by byte sequences in the authentication phase before encryption). A SIEM rule correlating observed handshakes with subsequent credential use can flag suspicious patterns. Endpoint detection: Audit UltraVNC configuration files and registry entries (Windows) to identify which authentication method is active; log any switches to MS-Logon II. Credential monitoring: Implement password change auditing for accounts used with UltraVNC; any unexpected changes may indicate silent compromise. Threat hunting: Review network packet captures or flow data from periods when UltraVNC was in use to check for signs of credential exfiltration or lateral movement originating from remote sessions.

Why prioritize this

This vulnerability should be prioritized as HIGH for any organization using UltraVNC with MS-Logon II authentication. The combination of passive exploitability, direct credential disclosure, and potential impact on high-privilege remote access justifies immediate configuration review and mitigation. Even organizations that have already upgraded should verify the authentication method in use, because legacy configurations may remain active inadvertently. If UltraVNC is used for administrative or sensitive-system access, prioritization should be CRITICAL.

Risk score, explained

The CVSS 3.1 score of 7.4 (HIGH) reflects a high-confidentiality impact (credentials disclosed) and high-integrity risk (attacker can impersonate user), balanced by the requirement for network-level observation (Attack Complexity High). No availability impact is assessed. The score appropriately captures the severity for most deployments; organizations using UltraVNC as a primary remote access tool or for privileged access should consider this vulnerability as functionally CRITICAL in their risk model, as credential compromise directly enables system takeover.

Frequently asked questions