TightVNC Pre-Auth RCE: Reading the Public PoC and Verifying Your Own Exposure
A public proof-of-concept for a TightVNC pre-authentication remote code execution flaw on Windows is circulating, per a report dated 2 November 2026. This walkthrough is defensive: it reads the bug path instead of running it, and it starts from what you can actually measure this week. What the video covers: - Why "pre-auth" is architectural. In RFB (RFC 6143) the server sends a version banner, the client replies, and both sides agree on a security type before any credential is checked. That negotiation is reachable by anyone who can open a socket. - A handshake-only probe that prints the server banner and the offered security types. Type 2 is VNC authentication; type 1 is security type None, where the framebuffer is handed to anyone who finishes the handshake. - The three-step path from an open port to code running inside the VNC service, which on a default Windows install is likely LocalSystem. Treat that as inference and confirm per host. - What the report does not state: no CVE identifier, no affected version range, no fixed build. Until an advisory lands, treat the entire pre-auth path as suspect rather than assuming the handshake parser is the component. - What reduces exposure now: inventory every host with tvnserver installed and its on-disk file version, restrict port 5900 at the network edge, and check which account the service runs under. The classic VNC DES challenge-response weakness is a separate issue with a separate fix. Patching this RCE does not make VNC authentication strong, and hardening VNC authentication does not remove this bug. Full write-up with the checks and mitigations: https://hackyjs.com/posts/tightvnc-pre-auth-rce-reading-the-public-poc-and-verifying-your-own-exposure