A Vulnerability That Strikes Before Login

A newly disclosed flaw in the TightVNC Viewer for Windows allows an attacker to execute arbitrary code on a victim’s machine before any password prompt or authentication step takes place. The research, credited to SeongJoon Cho of SSD Labs Korea, comes with a working proof-of-concept exploit built against TightVNC Viewer 2.8.88 x64, turning what might otherwise look like a theoretical bug into a demonstrated attack chain.

It is worth stressing which component is at risk. This is not a flaw in computers running a TightVNC server; it affects the viewer application that connects out to remote desktops. An attacker needs either network access to a viewer sitting in “Listening Mode” or the ability to lure a user into pointing their viewer at a server the attacker controls.

How a Screen-Size Field Becomes a Weapon

The root cause lies in how TightVNC handles the Remote Framebuffer protocol (RFB), the standard VNC uses to describe a remote screen. When a server announces its resolution, the viewer calculates how much memory it needs to store that image and stuffs the result into a 32-bit integer. Feed it a sufficiently large resolution, and that calculation wraps around, silently handing back a far smaller memory allocation than the screen actually requires.

In the documented proof-of-concept, a malicious server claims a screen measuring 32,768 by 32,769 pixels at 32 bits per pixel — an image that would require more than 4 GB to store. The viewer, fooled by the integer overflow, allocates only 128 KB. When the server then sends screen-update data, the viewer happily writes it past the end of that undersized buffer, corrupting adjacent memory.

From Memory Corruption to Code Execution

Memory corruption alone doesn’t guarantee an attacker can run their own code, but the published exploit shows how to get there. It first manipulates the length of an outgoing buffer to leak nearby memory contents, which reveals addresses an attacker needs to defeat Windows’ address space layout randomization (ASLR). From there, it hijacks a function pointer and strings together fragments of existing code — a technique known as return-oriented programming — to ultimately call Windows’ own CreateProcessW function and launch an arbitrary process.

Two paths bring a victim into range. A viewer left in Listening Mode exposes TCP port 5500 and, according to the disclosure, accepts inbound connections with no password and no IP filtering by default — meaning anyone who can reach that port can attempt the attack directly. Alternatively, a user who connects their own viewer outward to a rogue “support” server hands the same opportunity to whoever controls that server. Either way, the compromise happens before credentials are ever checked.

Not the Same as Password-Guessing Attacks

This bug is distinct from the VNC session hijacking that results from weak or reused passwords, and it’s also unrelated to cases where attackers trick victims into installing fake remote-access tools disguised as legitimate software. Here, the flaw lives inside the memory-handling logic of a trusted application, which is what makes a pre-authentication exploit possible in the first place.

Patch Status and What to Do Now

Researchers say they received no response from the vendor before disclosure. TightVNC’s own release notes point to security updates issued around October 2 and October 5, 2026, slightly muddying the exact patch timeline, but the vendor confirms that versions 2.8.89 and 2.8.90 close the viewer-side issues, with 2.8.90 recommended for anyone on that branch.

There is no evidence yet of active exploitation in the wild, but with public proof-of-concept code now available, that can change quickly. Security teams should treat this as urgent:

• Update every TightVNC Viewer installation to version 2.8.90 as soon as possible.
• Disable Listening Mode wherever it isn’t actively required.
• Restrict access to TCP port 5500 to trusted hosts only, using firewall rules.
• Avoid connecting viewers to unfamiliar or unverified VNC servers, including unsolicited “remote support” sessions.

Network-level restrictions reduce exposure but are not a substitute for patching the vulnerable viewer itself — until the update is applied, a reachable port or a single outbound connection to the wrong server is enough to hand an attacker code execution on the underlying Windows host.