CVE-2026-7830: UltraVNC Information Disclosure Flaw

CVE-2026-7830 Overview

CVE-2026-7830 affects UltraVNC through version 1.8.2.2. The vulnerability resides in the MS-Logon II authentication scheme (rfbUltraVNC_MsLogonIIAuth) implemented in rfb/dh.cpp. UltraVNC performs Diffie-Hellman (DH) key exchange using parameters that fit inside an unsigned 64-bit integer, and derives the private exponent from rand() values seeded by time(NULL). A network attacker who observes the MS-Logon II handshake can recover the shared DH key and decrypt the transmitted username and password. The flaw is classified under CWE-326: Inadequate Encryption Strength.

Critical Impact
Passive network observers can recover UltraVNC credentials in under a minute by breaking the 64-bit Diffie-Hellman exchange and predicting the time-seeded private exponent.

Affected Products

UltraVNC versions through 1.8.2.2
Deployments using the legacy MS-Logon II authentication scheme
MS-Logon III (X25519 + AES-256-GCM) is not affected

Discovery Timeline

2026-07-01 - CVE-2026-7830 published to NVD
2026-07-02 - Last updated in NVD database

Technical Details for CVE-2026-7830

Vulnerability Analysis

UltraVNC's MS-Logon II handshake wraps credentials in a symmetric key derived from a Diffie-Hellman exchange. The DH_MAX_BITS constant in rfb/dh.cpp constrains the prime size to values that fit within an unsigned 64-bit integer. A 64-bit DH modulus offers no meaningful security because Pollard's rho algorithm can solve the discrete logarithm in under one second on commodity hardware.

The implementation compounds the weakness by generating the DH private exponent inside a rng() helper that multiplies three libc rand() outputs. rand() is seeded from time(NULL), which yields roughly 31 bits of exploitable internal state. A passive observer who knows the approximate handshake time can enumerate seed candidates and reproduce the private exponent in under one minute.

Once either weakness is broken, the shared secret is known to the attacker. The encapsulated Windows domain username and password are recovered in cleartext, resulting in full credential disclosure.

Root Cause

The vulnerability combines two independent cryptographic defects. First, the DH parameters are undersized and cannot resist modern discrete-log attacks. Second, the private exponent is drawn from a non-cryptographic pseudo-random generator with a predictable seed. Either flaw alone would defeat the authentication scheme.

Attack Vector

An attacker requires network visibility of the MS-Logon II handshake. This can be achieved through passive sniffing on a shared segment, capture of recorded traffic, or an active man-in-the-middle position. No interaction with the client or server is required beyond observation. After recovering the shared key, the attacker decrypts the credential payload and can reuse those credentials for lateral movement.

// Vulnerability mechanism (prose description)
// 1. UltraVNC generates DH parameters where p fits in a uint64_t (DH_MAX_BITS <= 64)
// 2. Private exponent x = rand() * rand() * rand(), with srand(time(NULL))
// 3. Client and server exchange g^x mod p and g^y mod p over the wire
// 4. Attacker recovers x via Pollard's rho on the 64-bit group, OR
//    brute-forces the ~31-bit time-based seed to reproduce rand() outputs
// 5. Shared secret K = g^(xy) mod p is derived and used to decrypt credentials

Detection Methods for CVE-2026-7830

Indicators of Compromise

MS-Logon II handshakes observed on UltraVNC TCP sessions (typically port 5900) originating from clients running 1.8.2.2 or earlier
Successful VNC logons from source addresses not previously associated with the account or workstation
Reuse of captured domain credentials on non-VNC services shortly after a VNC session

Detection Strategies

Inspect VNC session metadata for the MS-Logon II security type negotiation and flag any sessions still using the legacy scheme
Correlate packet captures of VNC handshakes with subsequent authentication events using the same account across other systems
Alert on UltraVNC server versions at or below 1.8.2.2 discovered through asset inventory or vulnerability scanning

Monitoring Recommendations

Log all UltraVNC connection attempts, including negotiated authentication type and client version banners
Monitor egress traffic on VNC ports from segments that should not host remote administration tools
Track credential reuse across services following any VNC session to detect post-compromise lateral movement

How to Mitigate CVE-2026-7830

Immediate Actions Required

Disable MS-Logon II on UltraVNC servers and enforce MS-Logon III (X25519 + AES-256-GCM) for all remote sessions
Restrict UltraVNC network exposure to management VLANs or VPN-terminated segments
Rotate any Windows account credentials that were used with MS-Logon II over untrusted networks

Patch Information

No fixed version is listed in the current NVD entry. Consult the GitHub UltraVNC Repository and the UltraVNC Official Website for release updates addressing CVE-2026-7830. Until a patched build is available, treat MS-Logon II sessions as unauthenticated with respect to confidentiality.

Workarounds

Configure UltraVNC to require MS-Logon III exclusively and reject downgrade attempts
Tunnel VNC traffic through SSH or an IPsec/TLS VPN so that the vulnerable handshake is never exposed to an attacker
Segment administrator workstations away from general user networks to reduce passive sniffing opportunities

bash

# Example: block direct VNC exposure and force tunneling via firewall rules
# Deny inbound UltraVNC from untrusted zones
iptables -A INPUT -p tcp --dport 5900 -s 0.0.0.0/0 -j DROP
# Allow only from the administrative jump host over a VPN interface
iptables -A INPUT -i tun0 -p tcp --dport 5900 -s 10.10.0.0/24 -j ACCEPT