UltraVNC repeater through 1.8.2.2 contains a global buffer overflow in its embedded HTTP administration server. The functions wi_senderr() and wi_replyhdr() 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 (WI_RXBUFSIZE = 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 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 strcpy_s(saved_password, 64, "adminadmi2"). The HTTP Basic-auth handler wi_decode_auth() 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 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(m_netbuf, 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 viewer through 1.8.2.2 contains an off-by-one stack buffer overflow in the RFB ServerInit message handler. In vncviewer/ClientConnection.cpp, when the server-supplied nameLength equals exactly 2024 the code declares a 2024-byte stack buffer _dn[2024] and calls ReadString(_dn, 2024). ReadString writes the NUL terminator at buf[length], i.e., _dn[2024], one byte past the end of the stack buffer. A malicious VNC server can trigger this condition by advertising a desktop name of length 2024 in its ServerInit message. On release builds without stack canaries the single-byte NUL overwrite adjacent stack data. On builds with /GS stack protection the canary is corrupted and the process terminates, resulting in denial of service. User interaction (connecting the viewer to the malicious server) is required.

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.

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 strncpy_s 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 win_log() 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 (WI_RXBUFSIZE = 153600 bytes, well below SIZE_MAX 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 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.

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 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 wi_uudecode() 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.

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.

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 is a free and open source remote pc access software. A vulnerability has been found in versions prior to 1.3.8.0 in which the DSM plugin module, which allows a local authenticated user to achieve local privilege escalation (LPE) on a vulnerable system. The vulnerability has been fixed to allow loading of plugins from the installed directory. Affected users should upgrade their UltraVNC to 1.3.8.1. Users unable to upgrade should not install and run UltraVNC server as a service. It is advisable to create a scheduled task on a low privilege account to launch WinVNC.exe instead. There are no known workarounds if winvnc needs to be started as a service.

UltraVNC revision 1211 contains multiple memory leaks (CWE-665) in VNC server code, which allows an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.

UltraVNC revision 1203 has out-of-bounds access vulnerability in VNC client inside RAW decoder, which can potentially result code execution. This attack appear to be exploitable via network connectivity. This vulnerability has been fixed in revision 1204.

UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer offer handler, which can potentially in result code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.

UltraVNC revision 1203 has out-of-bounds access vulnerability in VNC client inside Ultra2 decoder, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1204.

UltraVNC revision 1207 has multiple out-of-bounds access vulnerabilities connected with improper usage of SETPIXELS macro in VNC client code, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1208.

UltraVNC revision 1207 has multiple out-of-bounds access vulnerabilities connected with improper usage of ClientConnection::Copybuffer function in VNC client code, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. User interaction is required to trigger these vulnerabilities. These vulnerabilities have been fixed in revision 1208.

UltraVNC revision 1207 has out-of-bounds read vulnerability in VNC client code inside TextChat module, which results in a denial of service (DoS) condition. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1208.

UltraVNC revision 1206 has multiple off-by-one vulnerabilities in VNC client code connected with improper usage of ClientConnection::ReadString function, which can potentially result code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1207.

UltraVNC revision 1206 has stack-based Buffer overflow vulnerability in VNC client code inside FileTransfer module, which leads to a denial of service (DoS) condition. This attack appear to be exploitable via network connectivity. This vulnerability has been fixed in revision 1207.

UltraVNC revision 1210 has out-of-bounds read vulnerability in VNC client code inside Ultra decoder, which results in a denial of service (DoS) condition. This attack appear to be exploitable via network connectivity. This vulnerability has been fixed in revision 1211.

UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer handler, which can potentially result code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.

UltraVNC revision 1211 has multiple off-by-one vulnerabilities in VNC server code, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.

UltraVNC revision 1211 has a heap buffer overflow vulnerability in VNC server code inside file transfer request handler, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.

UltraVNC revision 1211 has multiple improper null termination vulnerabilities in VNC server code, which result in out-of-bound data being accessed by remote users. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.

UltraVNC revision 1211 has a stack buffer overflow vulnerability in VNC server code inside file transfer request handler, which can result in Denial of Service (DoS). This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1212.

UltraVNC revision 1198 has a buffer underflow vulnerability in VNC client code, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1199.

UltraVNC revision 1205 has stack-based buffer overflow vulnerability in VNC client code inside ShowConnInfo routine, which leads to a denial of service (DoS) condition. This attack appear to be exploitable via network connectivity. User interaction is required to trigger this vulnerability. This vulnerability has been fixed in revision 1206.

UltraVNC revision 1203 has multiple heap buffer overflow vulnerabilities in VNC client code inside Ultra decoder, which results in code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1204.

UltraVNC revision 1199 has a out-of-bounds read vulnerability in VNC code inside client CoRRE decoder, caused by multiplication overflow. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1200.

UltraVNC revision 1199 has a out-of-bounds read vulnerability in VNC client RRE decoder code, caused by multiplication overflow. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1200.

UltraVNC revision 1198 contains multiple memory leaks (CWE-655) in VNC client code, which allow an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1199.

UltraVNC revision 1198 has a heap buffer overflow vulnerability in VNC client code which results code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1199.