Port 5800 – VNC Web (Virtual Network Computing over HTTP)

Port 5800 is the default port for the VNC web interface — a browser-based, Java-applet VNC viewer that a VNC server serves over HTTP so you can reach a remote desktop without installing a native client. It’s the web front-door to a VNC server, not the remote-desktop protocol itself: the actual VNC session runs on the Remote Framebuffer protocol on port 5900. Servers like TightVNC, RealVNC, and UltraVNC embed a small HTTP server on 5800 (5800 + the display number, so display :0 is 5800, :1 is 5801) that hands the browser a Java-applet viewer; the applet then opens its own connection back to 5900 to carry the session. Because of that pairing, an open port 5800 is really a signpost — it tells you a VNC server is running, and the actual VNC service on 5900 is almost certainly listening too.

Why It’s Open

The VNC web viewer exists for convenience: point any browser at http://host:5800/, load the applet, and you’re on the remote desktop with nothing to install. That made it popular in environments with locked-down software policies, in IT support, and in data centers, and it’s baked into a lot of appliances — KVM-over-IP switches, lights-out and IPMI management cards, embedded devices, and older thin-client setups. On the server side it’s optional but on by default in several builds: TightVNC, older RealVNC, UltraVNC, and TigerVNC’s legacy Java viewer all listen on 5800 when the HTTP viewer is enabled.

The catch is that the feature is now largely obsolete. Modern browsers dropped support for Java (NPAPI) plugins years ago — Chrome in 2015, Firefox in 2017 — so the classic Java applet on 5800 usually won’t even run anymore. The port often stays open regardless, still advertising the VNC server behind it. Where you find 5800, its real counterpart is one scan away: check for VNC on port 5900, which is where the remote desktop actually lives.

Common Risks

It exposes a VNC server. The biggest risk on 5800 isn’t the web page — it’s what it points at. An open 5800 means a VNC server is running, and VNC’s exposure problems (no password, weak or default password, full unattended desktop takeover) live on port 5900. Treat 5800 as the lead and assess the 5900 service properly.
Obsolete Java applet. The viewer 5800 serves is a Java applet that today’s browsers can no longer load. It’s dead weight that keeps the server discoverable without adding any legitimate use — and any old Java runtime still kept around for it is its own liability.
Plaintext HTTP. The 5800 viewer is served over unencrypted HTTP by default, so the page and anything it exchanges cross the wire in cleartext and can be sniffed or tampered with on the path.
Fingerprintable exposure. The 5800 HTTP response readily identifies the product and often the version, giving an attacker exactly what they need to look up matching VNC-server issues before they ever touch 5900.

Want to save time on reporting?

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

Enumeration & Testing

nmap -sV -p 5800,5900 <target>

Scan 5800 and 5900 together — an open 5800 almost always means the VNC service on 5900 is up too, and 5900 is where the real testing happens.

Fetch the VNC HTTP viewer page

curl -I http://<target>:5800/

A response identifying a small embedded web server (and often the VNC product/version) confirms you’re looking at a VNC web front-door rather than a general-purpose web app.

Grab the raw HTTP headers with netcat

nc -nv <target> 5800

Pivot to the real VNC service on 5900

nmap -sV -p 5900 --script vnc-info,vnc-auth <target>

The authentication and takeover testing belongs on 5900 — see the VNC on port 5900 page for vnc-info / vnc-auth, vncviewer, and brute-force workflow.

Log every VNC web front-door you find, together with the 5900 service behind it, so it lands in the final pentest report instead of a scratch file.

What to Look For

Checkpoint	What it means
5800 HTTP page loads a VNC Java applet	A VNC server is running — 5900 is the real target
5900 open alongside 5800	Confirm and test the VNC service there, not on 5800
Product/version in the 5800 response	Fingerprint to match known VNC-server issues
Java applet won’t run in the browser	Expected — plugins are dead; the exposure remains
Served over plain HTTP (no TLS)	Page and traffic are sniffable in transit
Reachable from the internet	VNC web viewer should never be internet-facing

Known CVEs and Exploits

There is no vulnerability specific to “port 5800” — the HTTP viewer is just a delivery page, and the security-relevant surface is the VNC server itself, which listens on 5900. Verified VNC-server issues (RFB parsing bugs, authentication weaknesses, LibVNC/TightVNC/UltraVNC flaws) are catalogued on the VNC port 5900 page, which owns that depth.

A caution on the CVEs that circulate for this port: several commonly-copied “port 5800 VNC” entries do not describe the VNC web interface at all. CVE-2020-25137 is a cross-site scripting bug in Observium, and CVE-2021-28109 is reflected XSS in TranzWare — neither touches VNC. CVE-2019-15681 is real but is a LibVNCServer memory-leak/information-disclosure issue on the VNC server, so it belongs with port 5900, not the 5800 web page. When you find an open 5800, don’t chase a “5800 CVE” — fingerprint the product and assess the VNC service on 5900.

Mitigation

Don’t expose VNC to the internet. Neither 5800 nor 5900 should be reachable from the public internet. Put remote desktop behind a VPN or an SSH tunnel and firewall both ports to a trusted management range.
Disable the HTTP/Java web viewer. The 5800 interface is legacy and, with browser Java support gone, almost never needed. Turn it off in the server config (for example, disable the built-in HTTP server / Java viewer option) so the port closes and stops advertising the VNC host.
Harden the VNC server on 5900. A strong, unique VNC password, encryption, current patches, and network segmentation are what actually protect the desktop — see the port 5900 page for the full VNC hardening checklist.
Retire the Java applet. If browser access is genuinely required, replace the dead Java-applet viewer with a modern HTML5/WebSocket VNC client (such as noVNC) rather than leaving the obsolete 5800 interface exposed.
Rescan after changes. Once you’ve disabled the HTTP viewer, confirm 5800 is closed — and verify 5900 is locked down or firewalled — with a fresh scan.

Real-World Example

The VNC web viewer is a casualty of the browser world moving on. When Chrome removed NPAPI plugin support in 2015 and Firefox followed in 2017, the Java applet that port 5800 exists to deliver simply stopped running in mainstream browsers. The feature became functionally dead — but the servers didn’t notice. Internet-wide scans (Shodan and similar) still routinely turn up VNC hosts with the 5800 HTTP viewer enabled, and the pattern is consistent: where 5800 is exposed, an accessible VNC service sits on 5900 behind it, often with weak or no authentication. It’s a clean illustration of why 5800 matters to a defender — not because the old web page is dangerous, but because it’s a reliable beacon pointing at the remote-desktop service that is.

FAQ

What is port 5800 used for?

Port 5800 serves a VNC server’s browser-based viewer — a small HTTP page and Java applet that lets you connect to a remote desktop without a native VNC client. The applet then talks to the actual VNC service on port 5900.

What’s the difference between port 5800 and port 5900?

Port 5800 is the optional HTTP/Java web front-door; port 5900 is the VNC remote-desktop protocol (RFB) itself. 5800 just delivers a viewer to your browser, while 5900 carries the real session. Both are offset by the display number (5800/5900 for :0, 5801/5901 for :1, and so on).

Why won’t the VNC Java viewer on port 5800 load in my browser?

Because modern browsers removed support for Java (NPAPI) plugins — Chrome in 2015, Firefox in 2017 — so the applet can no longer run. The port often stays open anyway; if you need browser-based VNC, use an HTML5 client like noVNC instead.

Is port 5800 dangerous, and how do I close it?

The page on 5800 isn’t the threat — it’s what it reveals: an exposed VNC server. Disable the HTTP/Java viewer in your VNC server config to close 5800, keep VNC off the public internet (VPN or SSH tunnel only), and harden the VNC service on 5900 with a strong password and encryption.

TL;DR

Service: VNC web interface — an HTTP server and Java-applet viewer (TightVNC, RealVNC, UltraVNC)
Default port: 5800/TCP (5800 + display number; the real VNC session runs on 5900)
Biggest risk: it advertises an exposed VNC server — the takeover surface lives on 5900, not the 5800 page
Note: the Java applet is obsolete (browsers dropped plugin support); there’s no port-5800-specific CVE
Mitigation: disable the HTTP/Java viewer, keep VNC off the internet (VPN/SSH tunnel), and harden 5900