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 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 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.
Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in The Wikimedia Foundation Mediawiki - Cargo Extension allows Stored XSS.
This issue affects Mediawiki - Cargo Extension: from * before 3.9.1.
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.
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.
runc is a CLI tool for spawning and running containers according to the OCI specification. In versions prior to 1.3.6, 1.4.0-rc.1, 1.4.0-rc.12, 1.5.0-rc.1, and 1.5.0-rc.1, when setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory. This issue is not exploitable under Docker, because Docker creates a top-level read-only layer that masks any malicious /dev symlink present in the container image — unlike some other Linux container tooling, whose higher-level runtimes built on runc remain exposed to exploitation via a malicious image. This issue has been fixed in versions 1.3.6, 1.4.3 and 1.5.0.
containerd is an open-source container runtime. In versions prior to 1.7.33, 2.3.2, 2.2.5, 2.1.9, and 2.0.10 the CRI plugin propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations. This issue has been fixed in versions 1.7.33, 2.3.2, 2.2.5, 2.1.9, and 2.0.10.
A malicious LDAP server, which a Thunderbird user is configured to query for address-book autocomplete, can stash arbitrarily large amounts of attacker-supplied data into the Thunderbird LDAP client until it crashes due to memory exhaustion. This vulnerability was fixed in Thunderbird 152.0.1 and Thunderbird 140.12.1.