My VNC server is accessible without a password. What should I do?
An open VNC server with no password is the digital equivalent of leaving your unlocked computer on a public street. Anyone who connects sees your live desktop and controls the keyboard and mouse — full, interactive access to the machine and everything you’re signed into. Disconnect it from the internet now.
First: don’t panic — but cut its network access immediately.
This is hands-on-keyboard access, so speed matters. Firewall the VNC port or pull the machine off the network right away, then assume someone may already have been in and investigate.
// the 60-second version
- Firewall port 5900 (and 5901+) now, or disconnect the machine.
- Require a strong VNC password; better, tunnel VNC over SSH/VPN.
- Assume full compromise — change passwords and hunt for persistence.
- Review sessions and logs for unauthorized control.
01Understand what’s at risk
VNC mirrors a real desktop session. Without authentication, anyone reaching the port gets:
- Full interactive control — they see your screen and drive mouse and keyboard as if sitting at the machine.
- Everything you’re logged into — email, banking, admin panels, saved sessions and password managers.
- File access & command execution — open a terminal, read files, install software, pivot to other systems.
- Persistence — plenty of time to add accounts, keys or remote-access tools.
Scanners and search engines like Shodan constantly index open VNC — and even screenshot the desktops they find. Assume an unauthenticated, internet-reachable VNC has been seen, and possibly used, and treat the machine as compromised.
02Stop the bleeding — cut network access
Make the port unreachable. Firewall it; if this is a sensitive machine and you suspect active access, disconnect it from the network while you investigate.
ufw deny 5900 ufw deny 5901
Configure the VNC server to listen on localhost only, then reach it through an SSH tunnel or VPN rather than directly:
ssh -L 5900:localhost:5900 user@host
03Require strong authentication
- Set a strong, unique VNC password — never run with authentication disabled.
- Prefer a server that supports real encryption, or always tunnel over SSH/VPN; classic VNC auth is weak and unencrypted on its own.
- Disable VNC entirely if you don’t actually need remote GUI access.
04Assume compromise — change credentials & hunt for persistence
Because VNC grants full control, treat the host as breached until proven otherwise:
- Change the passwords of every account used on that machine, and anything you were logged into during the exposure.
- Check for new user accounts, SSH
authorized_keys, scheduled tasks and unfamiliar remote-access tools. - Review installed software and running processes for anything you didn’t put there.
05Read the logs — was anyone connected?
Check the VNC server and system logs for connections and sessions around the exposure window:
# entries vary by server (RealVNC/TigerVNC/x11vnc) grep -iE "vnc|RFB|authenticated|connection" /var/log/syslog last -aw | head
- Connections from unknown IPs, or sessions when nobody was working, indicate unauthorized access.
- Cross-check auth logs for logins or
sudothat followed a VNC session.
06Make sure it can’t happen again
- Never expose VNC directly — always SSH tunnel or VPN.
- Require strong, unique passwords and encryption.
- Disable VNC when unused, and firewall remote-access ports by default.
- Monitor for connections from new IPs.
Was this guide useful?
These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.