See how ultravnc compares to other vendors in security performance
UltraVNC repeater through 1.8.2.2 contains a global buffer overflow in its embedded HTTP administration server. The functions wisenderr() and wireplyhdr() in repeater/webgui/webutils.c write the caller-supplied HTTP request URI into a fixed 1000-byte global buffer (hdrbuf) via unchecked sprintf calls. The HTTP receive buffer accepts URIs up to approximately 150 KB (WIRXBUFSIZE = 153600), so an unauthenticated attacker who can reach the repeater HTTP port (default TCP 80) can overflow hdrbuf by at least 500 bytes with a single HTTP request containing a URI of 1500 bytes or longer, corrupting adjacent .bss-segment globals. The overflow occurs before any authentication check, making it reachable without credentials. A remote, unauthenticated attacker can achieve arbitrary code execution on the host running the repeater.
UltraVNC viewer through 1.8.2.2 contains an integer overflow leading to a heap buffer overflow in the RFB protocol failure-response parsing path. In vncviewer/ClientConnection.cpp, the 4-byte network-supplied reasonLen field (type CARD32) is passed as reasonLen+1 to CheckBufferSize(). Because both operands are unsigned 32-bit, a reasonLen of 0xFFFFFFFF overflows to 0, causing CheckBufferSize to allocate only 256 bytes. The subsequent ReadString(mnetbuf, reasonLen) call then performs ReadExact for the original 4 GiB length into that 256-byte heap buffer. This overflow is reachable via rfbConnFailed (auth-scheme negotiation) and rfbVncAuthFailed (post-handshake) message types without successful authentication. A malicious VNC server, or any man-in-the-middle on the RFB stream, can trigger this condition when the victim viewer connects, potentially resulting in remote code execution as the user running the viewer. The crash was confirmed with AddressSanitizer on a portable reproduction harness (heap-buffer-overflow WRITE at offset 256).
UltraVNC repeater through 1.8.2.2 initializes the HTTP administration server with a hardcoded default password. In repeater/webgui/settings.c:197, when settings2.txt is absent on first run the repeater writes the literal string "adminadmi2" as the admin password via strcpys(savedpassword, 64, "adminadmi2"). The HTTP Basic-auth handler widecodeauth() checks this password without rate-limiting or lockout. Any remote attacker who can reach the repeater HTTP port (default TCP 80) can authenticate as administrator using the well-known default credential on a fresh or unmodified installation, gaining full control of the repeater configuration including allow/deny rules and session visibility.
UltraVNC repeater through 1.8.2.2 contains a post-authentication out-of-bounds write in the allow/deny rule parser. In repeater/webgui/settings.c:225-272, after strncpys copies a rule token into temp1[rule1] (25-byte destination) or temp2/temp3 (16-byte destination), the code unconditionally writes a NUL terminator at temp1[rule1][len] = 0 without clamping len to the destination size. When an authenticated administrator saves a rule with a token length equal to or greater than the destination size, the NUL byte is written one or more bytes past the end of the stack-allocated array, corrupting adjacent stack data. An attacker who has obtained admin credentials (including via CVE-2026-7839 default password) can trigger this to gain code execution on the repeater host.
UltraVNC repeater through 1.8.2.2 contains an integer overflow in the HTTP request logging path. In repeater/webgui/settings.c:336, the winlog() function allocates list nodes via malloc(sizeof(struct LIST) + strlen(line)), where line is derived from HTTP request URIs. If strlen(line) is sufficiently large, the addition overflows to a value smaller than sizeof(struct LIST), causing a heap allocation smaller than required. The subsequent strcpy of the full string into the undersized allocation produces a heap buffer overflow. In the current implementation this overflow is bounded by the HTTP receive buffer size (WIRXBUFSIZE = 153600 bytes, well below SIZEMAX on 32-bit builds), limiting practical exploitability to a partial heap write. A remote unauthenticated attacker can trigger the theoretical overflow path by sending a maximally-sized URI in an HTTP request to the repeater HTTP port.
UltraVNC repeater through 1.8.2.2 contains an off-by-one error in the Base64 decode helper used for HTTP Basic authentication. In repeater/webgui/webutils.c:817, the wiuudecode() function checks whether the input length exceeds the output buffer with a strict greater-than comparison (>), while the correct check should be greater-than-or-equal (>=). When strlen(authdata) equals sizeof(decode), the decoded output length (approximately 3/4 of input) does not overflow the buffer in current practice because the outer HTTP request bounds constrain the Authorization header. However, the defective check leaves a latent off-by-one condition that could become exploitable if the buffering constraints change. The current risk is limited to a one-byte write at the boundary of a 1024-byte stack buffer under constrained conditions.
UltraVNC through 1.8.2.2 contains an out-of-bounds read in the wide-string to multibyte conversion helper. In rfb/dh.cpp:204, the vncWc2Mb() function passes a caller-supplied WCHAR pointer to wcslen() before any bounds check. If the caller provides a wide-character buffer that is not properly NUL-terminated, wcslen() reads past the end of the buffer until it encounters a NUL wchar, resulting in an out-of-bounds read. Under typical Win32 API usage this requires an abnormal caller contract. Impact is limited to a potential information disclosure from adjacent memory regions or a process crash (denial of service) if the over-read crosses a page boundary.
UltraVNC through 1.8.2.2 uses a cryptographically weak pseudo-random number generator to produce VNC authentication challenge bytes. In rfb/vncauth.c:119-129, the vncRandomBytes() function seeds libc rand() with time(0) + getpid() + rand() and generates a 16-byte challenge. The combined seed space is approximately 31 bits (libc rand() internal state) and is entirely determined by publicly-observable values (wall-clock time and process ID). An attacker who can observe the authentication exchange can enumerate the seed space and predict the challenge within seconds, enabling forgery or offline brute-forcing of responses. Note: on Windows, the active code path may use vncEncryptBytes2.cpp which calls CryptGenRandom; reachability on shipped Windows binaries requires compile-graph verification and is under investigation.
Multiple integer signedness errors in (1) UltraVNC 1.0.2 and 1.0.5 and (2) TightVnc 1.3.9 allow remote VNC servers to cause a denial of service (heap corruption and application crash) or possibly execute arbitrary code via a large length value in a message, related to the (a) ClientConnection::CheckBufferSize and (b) ClientConnection::CheckFileZipBufferSize functions in ClientConnection.cpp.
A security flaw has been discovered in UltraVNC up to 1.6.4.0. Affected by this issue is some unknown functionality in the library version.dll of the component Service. The manipulation results in uncontrolled search path. The attack needs to be approached locally. This attack is characterized by high complexity. The exploitation is known to be difficult. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
UltraVNC Viewer 1.2.2.4 contains a denial of service vulnerability that allows attackers to crash the application by supplying an oversized string to the VNC Server input field. Attackers can paste a malicious string containing 256 repeated characters into the VNC Server field and click Connect to trigger a buffer overflow that crashes the viewer.
UltraVNC Launcher 1.2.2.4 contains a buffer overflow vulnerability in the Path vncviewer.exe property field that allows local attackers to crash the application by supplying an excessively long string. Attackers can input a 300-byte payload of repeated characters through the Properties dialog to trigger a denial of service condition.
A weakness has been identified in UltraVNC 1.6.4.0 on Windows. This affects an unknown function in the library cryptbase.dll of the component Windows Service. This manipulation causes uncontrolled search path. The attack requires local access. A high degree of complexity is needed for the attack. The exploitability is reported as difficult. The vendor was contacted early about this disclosure but did not respond in any way.
UltraVNC Viewer 1.2.4.0 contains a denial of service vulnerability that allows attackers to crash the application by manipulating VNC Server input. Attackers can generate a malformed 256-byte payload and paste it into the VNC Server connection dialog to trigger an application crash.
UltraVNC Launcher 1.2.4.0 contains a denial of service vulnerability in the Repeater Host configuration field that allows attackers to crash the application. Attackers can paste an overly long string of 300 characters into the Repeater Host property to trigger an application crash.
UltraVNC Launcher 1.2.4.0 contains a denial of service vulnerability in its password configuration properties that allows local attackers to crash the application. Attackers can paste an overly long 300-character string into the password field to trigger an application crash and prevent normal launcher functionality.
Untrusted search path vulnerability in UltraVNC 1.0.8.2 allows local users to gain privileges via a Trojan horse vnclang.dll file in the current working directory, as demonstrated by a directory that contains a .vnc file. NOTE: some of these details are obtained from third party information.
The MS-Logon authentication scheme in UltraVNC (aka Ultr@VNC) 1.0.1 uses weak encryption (XOR) for challenge/response, which allows remote attackers to gain privileges by sniffing and decrypting passwords.
Multiple buffer overflows in (a) UltraVNC (aka Ultr@VNC) 1.0.1 and earlier and (b) tabbedviewer 1.29 (1) allow user-assisted remote attackers to execute arbitrary code via a malicious server that sends a long string to a client that connects on TCP port 5900, which triggers an overflow in Log::ReallyPrint; and (2) allow remote attackers to cause a denial of service (server crash) via a long HTTP GET request to TCP port 5800, which triggers an overflow in VNCLog::ReallyPrint.
Multiple stack-based buffer overflows in multiple functions in vncviewer/FileTransfer.cpp in vncviewer for UltraVNC 1.0.2 and 1.0.4 before 01252008, when in LISTENING mode or when using the DSM plugin, allow remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via unspecified parameters, a different issue than CVE-2008-0610.
Stack-based buffer overflow in the ClientConnection::NegotiateProtocolVersion function in vncviewer/ClientConnection.cpp in vncviewer for UltraVNC 1.0.2 and 1.0.4 before 01252008, when in LISTENING mode or when using the DSM plugin, allows remote attackers to execute arbitrary code or cause a denial of service (crash) via a modified size value.
UltraVNC Repeater before 1300 does not restrict destination IP addresses or TCP ports, which allows remote attackers to obtain open-proxy functionality by using a :: substring in between the IP address and port number.