A newly disclosed vulnerability in the TightVNC Viewer allows attackers to execute code on Windows machines before a password prompt appears. Research credited to SeongJoon Cho of SSD Labs Korea includes proof-of-concept exploit code targeting TightVNC 2.8.88 x64. The flaw affects the viewer component and can be triggered when a viewer connects to a malicious server or when the viewer is reachable in Listening Mode.
How the bug works
The vulnerability traces to the Remote Framebuffer (RFB) protocol’s screen-size handling. When a VNC server announces very large screen dimensions, TightVNC’s viewer calculates the required memory but converts that value into a 32-bit integer. Extremely large dimensions cause the value to wrap, producing a much smaller allocation than required. For example, a server that reports a 32,768-by-32,769 screen with 32 bits per pixel can force the viewer to allocate roughly 128 KB while still holding dimensions that imply more than 4 GB of pixel data. Subsequent screen updates then write outside the undersized buffer because pointer arithmetic lacks a check against the allocated size.
Turning memory corruption into code execution
The published proof-of-concept exploits this out-of-bounds write to first leak nearby memory by altering an outgoing buffer length, which reveals addresses needed to bypass address space layout randomization (ASLR). The exploit then redirects a function call and uses return-oriented programming (ROP) to reuse existing code paths, ultimately invoking Windows’ CreateProcessW to launch a process. The disclosure demonstrates that the memory corruption can be escalated into remote code execution (RCE) on the target system.
Who and how this can be exploited
The flaw is in the TightVNC Viewer, not the server. Two practical attack routes are described:
- Direct targeting of viewers in Listening Mode: Listening Mode exposes the viewer on TCP port 5500 and accepts incoming server connections without a password or IP restriction, allowing an attacker who can reach that port to directly target the viewer.
- Outbound connections to attacker-controlled servers: If a user connects their viewer to a malicious VNC server, exploitation can occur before authentication, because the vulnerability triggers during initial screen negotiation.
The researchers note that the supplied disclosure does not establish active exploitation in the wild.
Vendor response and affected versions
The researchers reported the issue to the vendor but say there was no response; the patch timeline in public notes is slightly inconsistent. The disclosure reports the vendor patched the issue on October 3, 2026, while TightVNC’s release notices reference October 2 and October 5 security updates. TightVNC’s release notes identify Viewer security fixes in versions 2.8.89 and 2.8.90 and recommend version 2.8.90 for that branch. The PoC specifically targets TightVNC 2.8.88 x64.
Mitigations and operational guidance
The disclosure and accompanying reporting recommend administrators update affected viewers to the patched releases. Additional steps noted include disabling unnecessary Listening Mode, restricting access to TCP port 5500 to trusted systems, and avoiding connections to untrusted VNC servers. The report emphasizes that network restrictions help reduce exposure but do not replace patching the vulnerable viewer. Security operations teams (SOC) are encouraged to integrate the alert context and relevant threat intelligence to speed detection and response.
What to watch for
Because the vulnerability can be triggered before authentication and operates inside the viewer process, detection and containment depend on timely patching and reducing exposure (for example, by limiting Listening Mode and port access). The published PoC demonstrates the feasibility of RCE from crafted RFB negotiations, underscoring the risk to unpatched viewers.
Licensed under CC BY-ND 4.0 International