TightVNC Viewer · Public exploit code

Pre-auth RCE disclosed in TightVNC Viewer

Oct 29, 2026 · 1 min read

An r/netsec thread reports pre-authentication remote code execution in TightVNC Viewer. The item cites no affected versions or available fix. Users should wait for an official advisory before connecting the viewer to unknown servers.

By HIFY Radar newsroom Updated 10/29/2026 12:27 PM Get this every day →← Back to the feed 1 source

HighVulnerabilityPublic exploit codePatched

In this article

What happened
Why it matters
What to do
For the technical team
Timeline
Sources

What happened

TightVNC Viewer, a remote access tool common in help desk support, lets a malicious VNC server run code on the agent's computer before any password prompt. The flaw was publicly disclosed with technical details and exploit code. According to the research, the vendor already fixed the issue, but with no security advisory.

Why it matters

In listening mode, described as the usual help-desk deployment, the program binds 0.0.0.0:5500 with no password and no IP restriction: anyone on the network can attack. It is also enough for an agent to connect to an attacker-controlled server for the machine to be compromised before the password prompt. The result is code execution on the operator's workstation.

What to do

Update TightVNC Viewer to the latest version now; the fixed version was not stated. Block port 5500 on the network and disable listening mode where it is not needed. Instruct teams to connect only to known, trusted VNC servers.

For the technical team

Affected: TightVNC Viewer · TightVNC 2.8.88 x64 (version cited by SSD Secure Disclosure).
Exploitation: Technical details and exploit script (tvnexploit.py) published by SSD Secure Disclosure on October 29, 2026, credited to SeongJoon Cho (SSD Labs Korea). No reports of in-the-wild exploitation in the sources.
Fix: SSD states the vendor patched the vulnerability on October 3, 2026, without mentioning any security patch; fixed version not stated. Mitigation until updated: do not use listening mode, block port 5500, and connect only to trusted servers.
Vector: TightVNC Viewer (tvnviewer.exe), memory corruption via integer truncation. In rfb/FrameBuffer.cpp, getBufferSize computes the size in 64 bits then truncates with an (int) cast: an announced geometry of 32768x32769 at 32bpp yields a 128 KB allocation behind a 4 GB logical canvas. getBufferPtr computes the write offset in a 32-bit int using the announced width, with no bounds check: a server-controlled write at any signed offset from the framebuffer. RFB authentication is one-directional and the viewer accepts security type None. Conditions: listening mode (tvnviewer.exe -listen or GUI, binds 0.0.0.0:5500, no password, no IP restriction) or an outbound connection to an attacker-controlled server, compromised on connect before any password prompt.
More details: Chain: RFB handshake offering security type None; ServerInit with 32768x32769 allocates the truncated 128 KB buffer (FB1); out-of-bounds write poisons m_dataLength at FB1-0x440; next flush streams roughly 100 KB of adjacent heap back, leaking the tvnviewer.exe image base (RVAs 0xB6330, 0xEA950, 0xAC740) and FB1 to break ASLR; fake object and ROP chain written into FB1; overwrite of the BufferedOutputStream vtable pointer at FB1-0x18AF0; stack pivot at +0x06354A and CreateProcessW. Binary has ASLR and DEP on, CFG absent. Write path: RemoteViewerCore::receiveFbUpdateRectangle through the Raw and Tight decoders and DecoderOfRectangle::copy. SSD states it never received any response from the vendor to its report.