CVE-2026-7838 in UltraVNC
Summary
by MITRE • 07/01/2026
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).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/01/2026
The vulnerability exists within the UltraVNC viewer software version 1.8.2.2 and earlier, where an integer overflow condition leads to a heap buffer overflow during RFB protocol failure-response parsing. This flaw occurs in the vncviewer/ClientConnection.cpp file when processing network-supplied data from remote VNC servers. The core issue stems from how the 4-byte CARD32 field reasonLen is handled in the CheckBufferSize() function, which receives reasonLen+1 as a parameter. When reasonLen equals 0xFFFFFFFF, the unsigned 32-bit arithmetic causes an overflow that results in a value of 0, leading to inadequate buffer allocation of only 256 bytes instead of the intended large buffer size required for legitimate protocol responses.
The operational impact of this vulnerability is significant as it can be triggered through two distinct RFB message types without requiring successful authentication. The rfbConnFailed and rfbVncAuthFailed message types provide attack vectors that allow malicious actors to exploit this condition during the connection establishment phase or post-authentication handshake process. An attacker positioned as a man-in-the-middle on the RFB stream or controlling a malicious VNC server can initiate the overflow by sending specially crafted protocol messages with an oversized reasonLen field value. This vulnerability directly maps to CWE-190, which describes integer overflow conditions where a computation produces a result that exceeds the maximum value representable by the data type, and also aligns with ATT&CK technique T1210 for exploitation of remote services through protocol manipulation.
The buffer overflow condition manifests when ReadString() function attempts to read the original 4 gigabyte length string into the inadequately allocated 256-byte heap buffer, causing memory corruption that results in a heap-buffer-overflow WRITE operation at offset 256. This memory corruption pattern was successfully reproduced using AddressSanitizer on a portable test harness, confirming the vulnerability's exploitable nature. The crash occurs during normal user interaction when connecting to potentially malicious VNC servers, making it particularly dangerous in environments where users might connect to untrusted remote systems. The vulnerability presents a remote code execution risk as the attacker can potentially control the memory layout of the viewer process through this heap corruption, especially since the overflow occurs in a context where the viewer runs with the privileges of the connecting user.
Mitigation strategies should prioritize immediate software updates to versions that address this integer overflow condition, specifically those beyond 1.8.2.2 where the buffer size calculation has been corrected to properly handle the maximum CARD32 value. Network administrators should implement monitoring for suspicious RFB protocol traffic patterns and consider deploying network segmentation controls to limit exposure to untrusted VNC servers. The vulnerability demonstrates a classic example of how insufficient input validation combined with improper boundary checking can lead to critical memory corruption issues, reinforcing the importance of defensive programming practices including bounds checking and proper integer arithmetic handling in security-critical applications. Organizations should also consider implementing additional security layers such as VPN connections for VNC traffic or alternative remote access solutions that do not suffer from similar protocol-level vulnerabilities.