Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain sniffing or on-path position on VNC segment
-
DeliveryCapture MS-Logon II DH handshake
-
ExploitSolve 64-bit DH via Pollard's rho
-
ExecutionBrute-force time-seeded private exponent
-
PersistDerive shared key and decrypt blob
-
ImpactDisclose VNC username and password
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Encryption strength requirements
|
| Exploitation Conditions | Exploitation requires the target connection to use the legacy MS-Logon II authentication scheme (rfbUltraVNC_MsLogonIIAuth); connections using MS-Logon III (X25519 + AES-256-GCM) are immune. The attacker must be able to observe the authentication handshake on the network - via passive sniffing on a shared/switched segment, traffic recording, or an active man-in-the-middle/on-path position - which is the primary limiting factor and the reason CVSS scores AC:H rather than AC:L. No authentication is required (PR:N) and no user interaction beyond the victim initiating a normal login (UI:N). The attack is confined to UltraVNC on Windows through 1.8.2.2 and only yields credentials from handshakes the attacker can actually capture, so an attacker with no network vantage point cannot exploit it remotely at scale. |
| Impact | This is a genuine credential-exposure risk for environments still using legacy MS-Logon II, but exploitability is gated by network position rather than being drive-by remote. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4) correctly encodes that no authentication or user interaction is needed but that the attacker must be able to observe the handshake - hence AC:H. No EPSS score, KEV entry, or POC was provided, so there is no evidence of active exploitation; the cryptanalysis is well understood and reproducible, but weaponization requires privileged traffic access (LAN sniffing, ARP spoofing, or an on-path MITM). Net: prioritize where MS-Logon II is in use on untrusted or shared networks, but this is not an internet-scannable, mass-exploitable bug. The I:H rating in the supplied vector is debatable - the direct primary impact is confidentiality (credential disclosure); integrity impact is a downstream consequence of using the recovered credentials, so treat the I rating with caution and see the assessed vector below. |
| Exploit ScenarioDerived | An attacker on the same LAN segment as a VNC client and server (or positioned on-path via ARP spoofing) passively records the MS-Logon II handshake. They solve the 64-bit Diffie-Hellman exchange with Pollard's rho and recover the time-seeded private exponent by brute force within a minute, reconstruct the shared key, and decrypt the encapsulated username and password to obtain the operator's credentials. No public POC was provided, but the technique is fully described and reproducible from the CVE detail, and the AC:H rating reflects the required observation position. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 01, 2026
Credential disclosure in UltraVNC through 1.8.2.2 lets a passive network observer break the MS-Logon II authentication handshake and recover plaintext usernames and passwords. The rfbUltraVNC_MsLogonIIAuth scheme relies on a Diffie-Hellman exchange whose prime fits in an unsigned 64-bit integer and a private exponent derived from time(NULL)-seeded libc rand(), both of which are trivially solvable, so an attacker who sniffs or man-in-the-middles the exchange derives the shared key in seconds to a minute. There is no public exploit identified at time of analysis and no EPSS/KEV signal supplied; CVSS is 7.4 (AC:H reflecting the need to observe the handshake), and MS-Logon III (X25519 + AES-256-GCM) is not affected.
RemediationAI
No vendor-released patch version is identified at time of analysis (the references point to the vendor homepage https://uvnc.com/ and the repository https://github.com/ultravnc/UltraVNC, not to a tagged fixed release), so confirm the current fixed build directly with UltraVNC before relying on an upgrade. The most effective mitigation is to stop using MS-Logon II and switch authentication to MS-Logon III (X25519 + AES-256-GCM), which is unaffected; where MS-Logon II must remain, tunnel all VNC traffic through an encrypted transport such as an SSH tunnel, IPsec, or a VPN so the DH handshake is never observable in cleartext on the wire, accepting the added configuration and latency overhead. Additionally restrict VNC (typically TCP 5900/5901 and the 5800 web port) to trusted management networks via firewall rules and disable it on untrusted or shared LAN segments, with the trade-off of reduced remote reachability for legitimate operators. Rotate any credentials that may have traversed MS-Logon II sessions on untrusted networks, since prior handshakes could have been recorded for offline recovery.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in UltraVNC's RFB protocol extension for MS-Logon II, implemented in rfb/dh.cpp. Diffie-Hellman key agreement is meant to protect the encapsulated credential blob, but DH_MAX_BITS caps the prime at a size that fits in a 64-bit unsigned integer; a 64-bit discrete-log problem is solvable by Pollard's rho in under a second on commodity hardware. Compounding this, the private exponent comes from a custom rng() that multiplies three libc rand() outputs seeded from time(NULL), yielding roughly 31 bits of effective entropy tied to a guessable timestamp, so the exponent itself is brute-forceable in under a minute. This maps to CWE-326 (Inadequate Encryption Strength): the cryptographic primitive is structurally correct but uses parameter sizes and a PRNG far below any meaningful security margin. The affected component per CPE is cpe:2.3:a:uvnc:ultravnc:*:*:*:*:*:*:*:* - the UltraVNC server/viewer stack on Windows.
Know when Ultravnc gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
AC:H because the attacker must observe the handshake (sniff/MITM); PR:N/UI:N as no auth or interaction is needed; primary impact is credential confidentiality (C:H), with integrity/availability not directly affected.
Primary rating from Vendor (securin).
CVSS VectorVendor: securin
DescriptionCVE.org
UltraVNC through 1.8.2.2 uses inadequate cryptography in the MS-Logon II authentication scheme (rfbUltraVNC_MsLogonIIAuth). In rfb/dh.cpp the Diffie-Hellman key exchange is performed with parameters that fit in an unsigned 64-bit integer (DH_MAX_BITS controls the prime size). A 64-bit DH key can be broken by Pollard's rho algorithm in under one second on current hardware. Additionally, the private exponent is generated by the rng() function, which multiplies three libc rand() values seeded from time(NULL). With approximately 31 bits of internal state and a time-based seed, the private exponent is recoverable in under a minute by a passive observer. A network attacker who can observe the MS-Logon II handshake (via sniffing, recording, or man-in-the-middle) can derive the shared DH key and decrypt the encapsulated username and password, resulting in full credential disclosure. This affects legacy MS-Logon II connections; MS-Logon III (X25519 + AES-256-GCM) is unaffected.
Executive ViewAI
UltraVNC versions through 1.8.2.2 contain a critical weakness in MS-Logon II authentication that allows any attacker with network access to recover plaintext usernames and passwords through passive traffic observation. This credential disclosure directly enables unauthorized remote access to administrative systems, creating an elevated risk for any organization relying on UltraVNC for IT operations or remote support.
No vendor-released patch identified at time of analysis. Mitigations: (1) Migrate authentication method to MS-Logon III (X25519 + AES-256-GCM) if available in your deployed version; (2) Restrict UltraVNC connectivity to isolated internal networks and disable direct internet exposure; (3) Require VPN access as a prerequisite for all VNC connections; (4) Implement network segmentation and monitor for suspicious authentication patterns; (5) Evaluate alternative remote desktop solutions with FIPS-compliant cryptography.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Related Vulnerabilities in UltraVNC Memory Corruption and Cryptographic Flaws
View all 10UltraVNC Launcher 1.2.4.0 contains a denial of service vulnerability in the Repeater Host configuration field that allow
UltraVNC versions up to 1.6.4.0 suffer from an uncontrolled search path vulnerability in version.dll loaded by the Servi
UltraVNC Launcher 1.2.4.0 contains a denial of service vulnerability in its password configuration properties that allow
UltraVNC revision 1203 has out-of-bounds access vulnerability in VNC client inside RAW decoder, which can potentially re
UltraVNC revision 1211 has multiple improper null termination vulnerabilities in VNC server code, which result in out-of
UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer offer handler, w
UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer request handler,
UltraVNC revision 1211 has multiple off-by-one vulnerabilities in VNC server code, which can potentially result in code
UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer handler, which c
UltraVNC revision 1206 has multiple off-by-one vulnerabilities in VNC client code connected with improper usage of Clien
UltraVNC revision 1207 has multiple out-of-bounds access vulnerabilities connected with improper usage of ClientConnecti
UltraVNC revision 1207 has multiple out-of-bounds access vulnerabilities connected with improper usage of SETPIXELS macr
EUVD-2026-40882
GHSA-gf4x-6rw3-q4x6
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB