TightVNC Viewer bug lets a rogue server run code on your PC

Published

Connecting to the wrong VNC server, or simply leaving TightVNC Viewer listening for one, is enough to hand an attacker code execution on a Windows machine. Researchers at SSD Secure Disclosure published a detailed exploit write-up on 29 October for a flaw in TightVNC Viewer 2.8.88 for 64-bit Windows that fires before the viewer ever shows a password prompt.

The bug was found by SeongJoon Cho of SSD Labs Korea. SSD says it never received a response from the vendor, GlavSoft, but that the issue was patched on 3 October 2026 without any mention of a security fix. No CVE identifier or CVSS score has been published for it. Peru's national digital security centre (CNSD) flagged the issue to public and private organizations in its integrated digital security alert 215-2026 on 2 November.

One bad number at connection time

When a VNC session starts, the server tells the viewer how big its screen is, and the viewer sets aside memory to hold the picture. According to SSD, TightVNC's FrameBuffer::getBufferSize() multiplies width, height and bits per pixel in 64 bits, then truncates the result to a 32-bit integer. A server that announces a 32768 by 32769 screen at 32 bits per pixel therefore gets a buffer of just 128 KB, while the viewer still believes the canvas is enormous.

A second function, FrameBuffer::getBufferPtr(), works out where to write screen updates using 32-bit offsets based on that announced width, with no check against the real allocation. SSD describes the result as a server-controlled write at any signed offset from the framebuffer.

From a memory write to a running program

SSD's exploit chains that write with an information leak that recovers the program's image base and the framebuffer address, defeating ASLR (the Windows defence that randomizes where code sits in memory). It then hijacks a virtual function call, pivots the stack into the attacker-filled framebuffer, and uses a return-oriented programming chain to call CreateProcessW and launch a process. The researchers note the binary has ASLR and DEP enabled but lacks Control Flow Guard. Code runs in the context of the viewer process, meaning with the rights of whoever opened it.

There are two ways in, per the write-up:

The second scenario means the victim does not need to expose anything: persuading someone to connect to the wrong host is enough. Remote-access software is already a familiar part of intrusions, as in the campaign that quietly turned Korean PCs into proxies and VPNs. Neither SSD nor CNSD reports exploitation of this specific bug in the wild.

Update the viewer to 2.8.90 and close port 5500

TightVNC's own release notes list, for Viewer 2.8.89, added checks for oversized framebuffers before allocating pixel data, and Viewer 2.8.90 fixes a further buffer overrun in Tight-encoded screen data. Install 2.8.90 on every Windows machine that runs the viewer. Because the vendor did not label the October release as a security fix, administrators who skipped it had no reason to treat it as urgent.

Until every copy is updated, do not run the viewer in listening mode on any network you do not control, block inbound TCP 5500 at host and perimeter firewalls, and treat any request to connect to an unfamiliar VNC server as a red flag. The lesson here is less about one integer cast than about silent patches: a fix nobody announces is a fix nobody prioritizes, and the exploit is now public.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions