Port 5900 – VNC (Virtual Network Computing)

Port 5900 is the default port for VNC (Virtual Network Computing), a cross-platform remote-desktop protocol that lets one machine see and control another computer’s graphical desktop over a network. VNC speaks the Remote Framebuffer (RFB) protocol: the server streams the screen as pixels while the client sends back keyboard and mouse input. It’s the engine behind RealVNC, TightVNC, UltraVNC, TigerVNC, and macOS Screen Sharing, and it works the same way across Windows, Linux, and macOS. Listeners are assigned by display number — display :0 is 5900, :1 is 5901, and so on. Because a single working VNC connection hands over the live desktop, an exposed port 5900 is one of the highest-value findings on any host — and, unlike RDP on port 3389, classic VNC often ships with weak, truncated, or entirely absent authentication.

Why It’s Open

VNC is the go-to way to drive a graphical desktop remotely when you want something lightweight and cross-platform. You’ll find it on headless Linux servers and Raspberry Pis, macOS machines with Screen Sharing turned on, IT-support and help-desk workstations, virtual lab and classroom setups, and a huge amount of embedded and appliance gear — KVM-over-IP switches, IPMI and lights-out management cards, industrial HMIs and building-automation panels, and thin clients. Vendors bundle it because RFB is simple and clients exist for every platform. The trouble starts when that convenience faces the internet: a cloud VM with 5900 open, a home lab exposed through a router, or an HMI on a flat OT network. Where you find VNC, the rest of the remote-access surface is usually one scan away — the optional VNC web viewer on port 5800 that advertises the same server, RDP on port 3389 as the Windows equivalent, and SSH on port 22, which is what you should be tunnelling VNC through in the first place.

Common Risks

• No authentication at all. This is the headline VNC problem. Plenty of servers run with the password disabled, so anyone who reaches port 5900 gets an interactive desktop with no login step. Internet-wide scans (Shodan, nmap -p5900) routinely turn up hundreds of thousands of VNC servers, and a meaningful slice of them — including industrial HMIs and control screens — accept a connection with no credentials whatsoever.
• Weak passwords and the 8-character truncation. The classic VNC Authentication security type is a DES-based challenge-response, and the DES key is only 8 bytes — so the password is silently truncated to the first 8 characters. A 20-character passphrase provides no more strength than its first eight, which makes VNC passwords short by design and well within reach of brute-force and offline cracking.
• Authentication bypass. RealVNC 4.1.x let a client dictate the security type and force “Type 1 – None,” bypassing the password entirely (CVE-2006-2369). A single request, full desktop access, no credentials — a landmark VNC bug that is still probed for on legacy installs.
• No encryption by default. Classic VNC has no transport security. The whole session — the screen contents and every keystroke, credentials included — crosses the wire in cleartext unless it’s tunnelled over SSH/VPN or you’re using an encrypting variant, so anyone on the path can sniff or hijack it.
• Brute-force friendly, plus recoverable stored passwords. Most servers have no lockout or rate limiting, so password lists can be ground through freely. Stored VNC passwords are worse: they’re obfuscated with a fixed, publicly known DES key, so a config file or registry value is trivially decrypted back to plaintext.
• Implementation RCE bugs. The RFB parsers in LibVNCServer, UltraVNC, and TightVNC have carried a string of memory-corruption flaws that give code execution against exposed servers — or against a viewer that connects to a malicious server.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab version info

nmap -sV -p 5900 <target>

Query the protocol version and supported security types

nmap -p 5900 --script vnc-info <target>

vnc-info reports the RFB protocol version and the security types the server offers — this is where a “None” (type 1) entry immediately flags an unauthenticated desktop.

Check for the RealVNC authentication bypass

nmap -sV --script realvnc-auth-bypass <target>

The realvnc-auth-bypass NSE checks for CVE-2006-2369 by requesting the “None” security type even when it isn’t offered.

Brute-force the VNC password and read the desktop name

nmap -p 5900 --script vnc-brute,vnc-title <target>

vnc-brute audits the password; vnc-title then logs in with whatever vnc-brute (or the auth-bypass) found and returns the desktop name to confirm access.

Connect with a native client

vncviewer <target>::5900

Brute-force with Hydra

hydra -P /usr/share/wordlists/rockyou.txt vnc://<target>:5900

VNC’s classic authentication is password-only, so there’s no username to supply.

Metasploit modules

msfconsole -q
# Find servers that accept "None" authentication (no password)
use auxiliary/scanner/vnc/vnc_none_auth
set RHOSTS <target>
run

# Password-guess against VNC Authentication
use auxiliary/scanner/vnc/vnc_login
set RHOSTS <target>
set PASS_FILE passwords.txt
run

Record every exposed VNC server, no-auth hit, and cracked password as you confirm it so the evidence lands in the final pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

• CVE-2006-2369 — The RealVNC authentication bypass. RealVNC 4.1.0/4.1.1 (and products embedding it, such as AdderLink IP and Cisco CallManager) accept a client-chosen “Type 1 – None” security type even when the server never offered it, giving full access with no password. CVSS v2 base 7.5 (High). Checked by nmap’s realvnc-auth-bypass NSE and Metasploit’s auxiliary/scanner/vnc/vnc_none_auth.
• CVE-2018-7225 — LibVNCServer through 0.9.11. rfbProcessClientNormalMessage() in rfbserver.c doesn’t sanitize msg.cct.length, so crafted VNC packets reach uninitialized/sensitive memory and can trigger an integer overflow. CVSS 3.0 base 9.8 (Critical) — a server-side, pre-auth bug affecting anything built on LibVNCServer.
• CVE-2019-15681 — LibVNCServer through 0.9.12. A memory leak (CWE-655) in the VNC server code lets an attacker read stack memory, usable for information disclosure. CVSS 3.1 base 7.5 (High). (This is the real “5800/5900 LibVNC” CVE that circulates mislabelled elsewhere — it belongs to the VNC server, on 5900.)
• CVE-2019-8287 — TightVNC 1.3.10. A global buffer overflow in the HandleCoRREBBP macro (the viewer decoding a CoRRE rectangle) that can lead to code execution and is exploitable over the network — a malicious server attacking a connecting client. CVSS 3.1 base 9.8 (Critical).
• CVE-2018-15361 — UltraVNC before 1.2.2.3. A buffer underflow in the VNC client code that can result in code execution over a network connection (fixed in revision 1199). CVSS 3.0 base 9.8 (Critical). Part of Kaspersky’s 2019 VNC audit that reworked much of the LibVNC/UltraVNC/TightVNC parser surface.

A caution on copied CVE lists: several entries that get pasted onto “port 5900 VNC” pages are the wrong service entirely. CVE-2023-1547 is SQL injection in an Elra Parkmatik parking system, CVE-2022-4285 is a GNU binutils denial-of-service, CVE-2020-25791 is a Rust sized-chunks array bug, and CVE-2021-41064 is a rejected/unused identifier — none of them touch VNC. Fingerprint the actual VNC product and version, then match it against the verified issues above.

Mitigation

• Never expose VNC to the internet. Neither 5900 nor its web viewer on 5800 should be reachable from the public internet. Put the desktop behind a VPN or tunnel it over SSH on port 22, and firewall port 5900 to a trusted management range.
• Set a strong password — and mind the 8-character limit. Always require a VNC password, but remember the classic DES auth truncates it to 8 characters. For real strength, run a modern VNC build that supports proper authentication and encryption rather than relying on the legacy scheme.
• Enable encryption. Use a VNC variant or add-on that encrypts the session (or the SSH/VPN tunnel above); default RFB carries the screen and keystrokes in cleartext.
• Patch the VNC server and viewer. Keep RealVNC, TightVNC, UltraVNC, TigerVNC, and any LibVNCServer-based appliance current — this is what closes the RealVNC bypass and the LibVNC/UltraVNC/TightVNC RCEs above. Patch clients too; several of these bugs hit the viewer.
• Restrict source IPs and monitor. Limit who can reach 5900 with host and network firewall rules, log connections, and alert on access from unexpected networks.
• Prefer a better protocol where you can. On Windows, RDP on port 3389 with Network Level Authentication is a stronger default; for shell access, SSH on port 22 beats a full remote desktop. Reserve VNC for cases that genuinely need cross-platform GUI control.
• Rescan after changes. Once VNC is tunnelled or firewalled, confirm 5900 is no longer openly reachable with a fresh nmap -p 5900 <target>.

Real-World Example

In November 2019, Kaspersky ICS-CERT published a broad audit of the VNC ecosystem and found 37 memory-corruption vulnerabilities across four widely deployed codebases — LibVNC, UltraVNC, TightVNC 1.x, and TurboVNC — affecting roughly 600,000 internet-reachable VNC servers, many of them in industrial environments. The bugs (CVE-2018-15361 and the LibVNC cluster among them) ran in both directions: a malicious server could attack a connecting client, and a malicious client could attack an exposed server. But the more mundane finding is the one that keeps recurring: scan port 5900 across the internet and a large share of the servers answer with the “None” security type or a trivially guessed password, exposing live desktops — factory HMIs, building controls, utility panels, and ordinary workstations — to anyone who connects. VNC’s danger isn’t exotic; it’s a powerful remote-desktop protocol that too often sits on the internet with weak or absent authentication.

FAQ

What is port 5900 used for?

Port 5900 is the default port for VNC (Virtual Network Computing), a cross-platform remote-desktop protocol. A VNC server on 5900 streams its graphical desktop to a viewer using the Remote Framebuffer (RFB) protocol and accepts the viewer’s keyboard and mouse input. Additional displays use 5901, 5902, and so on.

Is port 5900 dangerous?

It can be, especially on an untrusted network. Classic VNC often runs with no password or a weak, DES-truncated one, sends everything in cleartext, and has carried authentication-bypass and remote-code-execution bugs. An internet-facing port 5900 is a high-value target and should be tunnelled or firewalled, not left open.

What service runs on port 5900?

A VNC server — commonly RealVNC, TightVNC, UltraVNC, TigerVNC, or macOS Screen Sharing — speaking the RFB protocol. The optional browser-based viewer on port 5800 front-ends the same server.

Does VNC use TCP or UDP?

VNC uses TCP. The RFB protocol is a reliable, connection-oriented stream, so the server listens on TCP 5900 (plus the display offset) and there is no UDP transport to scan.

How do I secure or close port 5900?

Take VNC off the public internet — reach it only through a VPN or an SSH tunnel on port 22 — then set a strong password on a build that supports proper authentication and encryption, patch the server and viewer, and firewall 5900 to trusted hosts. If a machine doesn’t need remote desktop, disable the VNC server and rescan with nmap -p 5900 <target> to confirm the port is closed.

TL;DR

• Service: VNC (Virtual Network Computing) over the RFB protocol — RealVNC, TightVNC, UltraVNC, TigerVNC, macOS Screen Sharing
• Default port: 5900/TCP (5900 + display number; the optional web viewer is on 5800)
• Biggest risk: exposed desktops with no or weak authentication — the 8-char DES truncation, the CVE-2006-2369 bypass, cleartext sessions, and LibVNC/UltraVNC/TightVNC RCEs
• Mitigation: never expose VNC directly — tunnel over SSH/VPN, require a strong password with encryption, patch server and viewer, and firewall 5900