RealVNC auth bypass

A RealVNC flaw let a client dictate the security type during the RFB handshake, so a malicious client selected None even though the server required a password. The server honoured the client's choice and granted an unauthenticated session, a complete authentication bypass against affected RealVNC versions.

1 min di letturaaggiornato il 5 ott 2026florianamette1 contributore
Chiedi al tuo assistente (MCP)Modifica su GitHub

CVE-2006-2369 affected RealVNC 4.1.0 and 4.1.1, as well as some products that embedded the vulnerable RealVNC code. During RFB security negotiation, the affected server failed to verify that the client's selected security type was one the server had offered. Selecting None (type 1) could therefore bypass the configured authentication check. Confirm the exact product and version before applying this historical finding.

bash
# check for CVE-2006-2369 behavior; this reports the result but is not a VNC viewer
nmap -sV -p5900 --script realvnc-auth-bypass <target>

Exploitation notes#

  • The flaw is the server accepting a security type it did not advertise.
  • Nmap's script checks for the vulnerable negotiation behavior; it does not provide an interactive desktop session.
  • A positive check indicates that a separate compatible VNC client could exploit the authentication bypass, subject to reachability and the embedded product's behavior.
  • Treat other RealVNC releases and products as unaffected unless their own advisory says otherwise.

References#

PrecedentePassword brute forceSuccessiva TightVNC bypass