Port 5901: VNC Display :1 — The First Virtual Screen

Port 5901 is the first step up the VNC display ladder. While port 5900 handles display :0 (typically the physical console), port 5901 carries display :1, the first virtual display. On headless servers, data centers, and cloud instances across the world, this is often the only screen that exists.

What VNC Does

Virtual Network Computing lets you see and control a computer's graphical desktop from anywhere on the network. You see what's on the screen. You move the mouse. You type on the keyboard. The computer responds as if you were sitting in front of it.

VNC works at the framebuffer level, which means it doesn't care what operating system or window manager you're running. It just captures pixels and sends them across the wire. This makes it universal: Windows, macOS, Linux, Unix, embedded systems. If it has a screen (or can pretend to have one), VNC can share it.

The Display Number Convention

VNC borrowed its port numbering from the X Window System. The formula is simple: 5900 + display number = port.¹

Display :0 usually refers to the physical console, the monitor actually plugged into the machine. Display :1 and above are virtual displays, created on demand for remote sessions.²

This is why port 5901 matters: on most Linux and Unix servers running VNC, display :1 is the first available virtual display. If you're connecting to a headless server (one with no physical monitor), there is no display :0 to share. The VNC server creates display :1 out of nothing, renders a desktop into memory, and serves it on port 5901.

How the RFB Protocol Works

VNC uses the Remote Framebuffer (RFB) protocol, defined in RFC 6143.³ The protocol is deliberately simple, designed so that the client can be as dumb as possible.

The core primitive is almost absurdly basic: "put a rectangle of pixel data at position (x, y)."⁴ That's it. A sequence of these rectangles makes a framebuffer update.

The connection works like this:

1. Version handshake: Client and server agree on a protocol version
2. Security negotiation: They agree on an authentication method
3. Initialization: Server tells the client the screen dimensions and pixel format
4. Operation: Client requests updates, server sends rectangles of pixels

The client drives everything. The server only sends screen updates when the client asks for them. This makes the protocol adaptive: slow networks get fewer updates, fast networks get more.⁵

To keep bandwidth manageable, RFB supports multiple encoding schemes for pixel data:

• Raw: Uncompressed pixels, works everywhere
• CopyRect: "Copy this rectangle from over there," perfect for window moves and scrolling
• ZRLE/TRLE: Compressed encodings used by modern implementations
• Hextile: An older encoding still supported for compatibility

The client tells the server which encodings it supports, and the server picks the best one for each rectangle.

The Cambridge Origins

VNC was created at the Olivetti Research Laboratory in Cambridge, UK, in the late 1990s.⁶ The project was led by Tristan Richardson, with key contributions from Andy Harter, Quentin Stafford-Fraser, James Weatherall, and Kenneth R. Wood.⁷

But the RFB protocol predates VNC itself. It was originally developed for something called the Videotile, a thin client device with an LCD screen connected via ATM (Asynchronous Transfer Mode) networking.⁸ The researchers needed a simple protocol to push display data to these minimal devices. They built RFB to be so thin that the client would need almost no processing power.

The Videotile project faded, but the protocol lived on. When the lab pivoted to building VNC, RFB was already there, waiting. VNC was released as open source software in 1998, and the protocol specification was published freely for anyone to implement.⁹

The lab passed through multiple owners: Olivetti, then Olivetti & Oracle Research Lab (1997), then AT&T Labs Cambridge (1999). When AT&T closed the Cambridge lab in 2002, several of the original VNC developers founded RealVNC Ltd. to continue development.¹⁰

Quentin Stafford-Fraser, who wrote the original Windows VNC client and server, was also part of another piece of Internet history. He's the person who pointed a camera at the Trojan Room coffee pot, creating what became the world's first webcam.¹¹ The same lab that gave us VNC gave us the ability to check if the coffee was ready.

Security: The Elephant in the Server Room

Here's the uncomfortable truth about VNC: the original protocol offers almost no security.

RFC 6143 states it plainly: "The RFB protocol as defined here provides no security beyond the optional and cryptographically weak password check."¹² The built-in VNC authentication uses a 56-bit DES challenge-response, which was already outdated when the RFC was written in 2011.

The security history is worse than that:

CVE-2006-2369 was a devastating authentication bypass in RealVNC 4.1.0 and 4.1.1. A malicious client could simply claim it wanted "no authentication" (security type 1), and the server would accept it, even if that option wasn't offered.¹³ The server trusted the client's claim about what authentication method to use. This affected not just RealVNC but any product embedding it, including Cisco CallManager.

37 vulnerabilities were found in 2019 across four major open-source VNC implementations (LibVNC, TightVNC, TurboVNC, UltraVNC), some of which had been present since 1999.¹⁴ These were primarily memory corruption bugs that could lead to denial of service or code execution.

Over 8,000 VNC instances are currently exposed to the Internet with no authentication at all.¹⁵ Researchers have found unauthenticated VNC access to SCADA systems, water treatment plants, and manufacturing facilities.¹⁶

The recommendation from the RFC itself is clear: don't use VNC's built-in security for anything sensitive. Tunnel it through SSH. Use a VPN. Layer real encryption underneath.¹⁷

The Scale of Exposure

Shodan searches reveal the scope of the problem. Over 600,000 VNC servers are directly accessible from the Internet.¹⁸ Most are concentrated in China, Sweden, the United States, Spain, and Brazil.¹⁹

Security researchers at Cyble documented a spike in attacks targeting port 5900 and its siblings, with the Netherlands, Russia, and Ukraine among the top sources of attack traffic.²⁰

For port 5901 specifically, the exposure is significant because it's the default first virtual display. When administrators set up VNC on a headless server, they often create display :1 without thinking about whether port 5901 should be reachable from outside.

Related Ports

Current Relevance

VNC remains one of the core technologies in the remote desktop software market, which is projected to grow from $3.3 billion in 2024 to nearly $12 billion by 2032.²¹ While newer protocols like RDP and proprietary solutions from TeamViewer and AnyDesk have captured significant market share, VNC's openness and cross-platform nature keep it relevant.

It's particularly common in:

• Headless server administration: Cloud instances and data center machines
• Linux/Unix environments: Where RDP isn't native
• Industrial control systems: Where equipment outlives the software trends
• Educational and research settings: Where open protocols matter
• KVM-over-IP devices: Hardware that provides remote console access

The RFB protocol continues to be maintained and extended. The community specification at rfbproto.github.io documents extensions beyond the original RFC.