VNC Server Unauthenticated Access (Nessus plugin 26925) means a VNC server offers the RFB “None” security type, so anyone who reaches the port gets the desktop without a password. Fix it by removing None, requiring a VNC password or system login, and restricting TCP 5900 and up to admin networks or an SSH or VPN tunnel.
What the scanner is actually detecting
The finding comes from Tenable Nessus plugin 26925, titled VNC Server Unauthenticated Access. It is a remote, unauthenticated check that needs no credentials on the target.
| Field | Value on the Tenable plugin page |
|---|---|
| Plugin name | VNC Server Unauthenticated Access |
| Plugin ID | 26925 (vnc_no_auth.nasl) |
| Severity | High (CVSS v2 base score 7.5) |
| Type and family | Remote, Misc. |
| Dependencies | vnc_security_types.nasl, os_fingerprint.nasl |
At the start of every VNC session the server lists the security types it accepts. RFC 6143 defines type 1 as None (no authentication) and type 2 as VNC Authentication. Nessus flags the host when None is on that list, and Tenable’s solution is simply to disable the No Authentication security type. The plugin output names the port. Each VNC display usually has its own port (5900 for display :0, 5901 for :1 and so on), so one host can carry several separate findings.
Real-world risk
Anyone who can reach the port sees the screen and, unless the server is set to view-only, types and clicks as the logged-in user. With an unlocked admin session that is full control of the host. On KVM-over-IP switches it can be the server console itself, and on industrial HMI panels the operator screen. RealVNC’s own parameter reference warns that None belongs only on direct connections to internal computers, because a simple port scan could otherwise lead to takeover.
Urgency depends on reachability. A VNC port reachable from the Internet should be fixed today, and it is worth checking your external attack surface management scope to find out how it got there. An internal-only instance is lower risk but still gives any compromised machine on that segment a free desktop. Note that RFC 6143 describes classic VNC Authentication as a cryptographically weak password check with no protection for session data: a password closes this finding, but encryption or a tunnel protects the traffic.
How to confirm it on the host
From the scanner’s network segment, the Nmap vnc-info script lists the offered security types and prints a warning when no authentication is required:
nmap -Pn -p 5900-5906 --script vnc-info <host>
# Security types:
# None (1)
# WARNING: Server does not require authenticationOn Linux, find the listener and the command line that started it:
sudo ss -tlnp | grep ':59'
ps -eo pid,user,args | grep -E '[x]11vnc|[X]vnc|[v]ncserver'
grep -riE 'securitytypes|localhost' /etc/tigervnc/ ~/.vnc/ ~/.config/tigervnc/ 2>/dev/null
sudo grep -rE '^(Authentication|GuestPermissions)' /etc/vnc/ /root/.vnc/config.d/ 2>/dev/nullAn x11vnc process without -rfbauth, -passwdfile, -usepw or -unixpw has no password, and an Xvnc started with SecurityTypes None offers no authentication. On Windows, use an elevated PowerShell prompt:
Get-NetTCPConnection -State Listen | Where-Object LocalPort -in 5900..5906
reg query "HKLMSOFTWARETightVNCServer"
reg query "HKLMSOFTWARERealVNCvncserver" /v Authentication
reg query "HKLMSOFTWAREPoliciesRealVNCvncserver" /v AuthenticationFor TightVNC, UseVncAuthentication set to 0 means no VNC authentication. For RealVNC, a value of None is the finding. For UltraVNC, open ultravnc.ini in the UltraVNC folder and look for AuthRequired=0 or an empty passwd line.
How to fix it
Back up first (see the rollback section), then require authentication and limit who can reach the port.
RealVNC Server
In VNC Server, open Options > Security and set Authentication to VNC password or System authentication. The underlying parameter is Authentication, with values such as VncAuth and SystemAuth. RealVNC says not to edit it on Lite or Essentials subscriptions, where it would break remote access. On Windows (Service Mode) the parameter is a string value under HKLMSoftwareRealVNCvncserver; setting it under HKLMSoftwarePoliciesRealVNCvncserver instead, for example through Group Policy, overrides the local value and locks it. On Linux (Service Mode), add it to /root/.vnc/config.d/vncserver-x11, or to /etc/vnc/policy.d/common to lock it:
Authentication=SystemAuth
Encryption=AlwaysOn
GuestPermissions=0sudo vncpasswd -service # only needed for Authentication=VncAuth
sudo vnclicense -reload # re-applies parameters to all running instancesGuestPermissions set to 0 prevents guests from bypassing the authentication scheme on direct connections.
TightVNC for Windows
Click the TightVNC Service tray icon, and on the Server tab check Require VNC authentication and set a primary password (and a view-only password if needed). On the Administration tab, protect control operations with an administrative password so local users cannot switch it back off. Service mode and application mode are configured separately, so fix both if both run. After editing settings offline, apply them to the running service:
"C:Program FilesTightVNCtvnserver.exe" -controlservice -reloadFor many machines, TightVNC’s MSI guide documents silent-install properties. Password properties only work in a silent installation and put the password on a command line, so protect your deployment logs:
msiexec.exe /i <tightvnc-installer>.msi /quiet /norestart SET_USEVNCAUTHENTICATION=1 VALUE_OF_USEVNCAUTHENTICATION=1 SET_PASSWORD=1 VALUE_OF_PASSWORD=<password>UltraVNC
Set the VNC password in the server’s admin properties (or uvnc_settings.exe) rather than by hand, because passwd is stored encoded. Then check these entries in ultravnc.ini and restart the UltraVNC server:
[admin]
AuthRequired=1
MSLogonRequired=1
NewMSLogon=1AuthRequired=1 makes the server refuse connections while the password is empty. The two MS-Logon settings are optional and switch to Windows account authentication with an access list.
x11vnc
x11vnc -storepasswd # prompts, writes ~/.vnc/passwd
chmod 600 ~/.vnc/passwd
x11vnc -display :0 -rfbauth ~/.vnc/passwd -localhost -foreverRemove -nopw from service units and scripts: it only hides the warning x11vnc prints when running without a password. Avoid -passwd, which exposes the password in the process list, and remember the rfbauth file is only obscured with a fixed key, not encrypted.
TigerVNC and other Xvnc servers
Xvnc defaults to TLSVnc,VncAuth, so None is present only if someone configured it. To enforce a policy for all users with the systemd-based vncsession, put this in /etc/tigervnc/vncserver-config-mandatory, have each user run vncpasswd, and restart with sudo systemctl restart vncserver@:1:
securitytypes=vncauth,tlsvnc
localhostKVM switches, BMCs and HMI panels
Embedded VNC servers are configured through the device’s own web interface or panel settings, so follow the vendor manual to set a password. If the device cannot require authentication, place it on a management network reachable only from a jump host.
Restrict who can reach the port
On Windows, find the existing allow rules (installers often add one), then replace them with a scoped rule:
Get-NetFirewallPortFilter | Where-Object LocalPort -eq 5900 | Get-NetFirewallRule | Select-Object DisplayName, Enabled, Profile
New-NetFirewallRule -DisplayName "VNC from admin subnet" -Direction Inbound -Protocol TCP -LocalPort 5900 -RemoteAddress 10.10.20.0/24 -Action Allow
Disable-NetFirewallRule -DisplayName "<broad rule found above>"On Linux with firewalld (the built-in vnc-server service opens 5900 to 5903 to everyone in the zone):
sudo firewall-cmd --permanent --remove-service=vnc-server
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.10.20.0/24" port port="5900-5903" protocol="tcp" accept'
sudo firewall-cmd --reloadThe strongest option is to bind VNC to localhost (x11vnc -localhost, TigerVNC localhost, RealVNC localhost=TRUE, UltraVNC LoopbackOnly=1, TightVNC’s loopback-only access control setting) and tunnel it over SSH:
ssh -L 5901:localhost:5900 admin@vnc-host
# then point the VNC viewer at localhost:5901How to verify the fix and rescan
- Run the vnc-info command again from the scanner’s segment. None (1) and the warning line must be gone for every port listed in the original plugin output.
- Connect with a viewer and confirm you are prompted for a password or account credentials before the desktop appears.
- From a subnet outside your allow list, confirm the port is filtered or refused.
- Rescan with the same Nessus policy and scanner. Plugin 26925 should no longer be reported. If the firewall now blocks the scanner entirely, that proves only one path is closed.
What can break and how to roll back
- Third-party viewers. RealVNC documents that VncAuth is the only scheme that allows direct connections from non-RealVNC viewers, so SystemAuth locks out TightVNC or UltraVNC viewers.
- Unattended clients. Scripts, monitoring tools, supervisory HMI software or KVM managers that connected without a password will fail until they are given credentials.
- Long passwords. VNC Authentication truncates the password to eight characters (RFC 6143), which surprises users who typed more.
- Localhost binding stops all direct connections until people have an SSH or VPN path.
Back up before changing anything, and restore the backup and reload if you must roll back. Keep the firewall restriction in place while you fix the clients.
reg export "HKLMSOFTWARETightVNC" C:Temptightvnc-before.reg
reg export "HKLMSOFTWARERealVNC" C:Temprealvnc-before.reg
sudo cp -p /root/.vnc/config.d/vncserver-x11 /root/vncserver-x11.bakCommon false positive reasons
- A display manager login screen. Tenable notes that some VNC servers send the user to an XDM login screen, which Nessus cannot recognize (TigerVNC documents this as Xvnc from inetd with securitytypes=none). A system login is still required, but the traffic is unencrypted, so accept the risk only with network restrictions in place.
- A different instance. You fixed the TightVNC service but an application-mode copy still runs, or RealVNC User Mode or Virtual Mode listens on another port. Match the port in the plugin output.
- A different device. A NAT or port-forward rule sends 5900 on the scanned address to a KVM, BMC or other host.
- The change was never applied. A config file was edited without a reload, or a RealVNC policy file overrides the value you set.
- An accept prompt is not authentication. A server that asks the local user to accept connections but still offers None is a valid finding.
FAQ
Is a VNC password enough?
It closes plugin 26925, but classic VNC Authentication is a DES challenge-response limited to eight characters and does not encrypt the session. Prefer system authentication with encryption, or keep VNC on localhost behind SSH or a VPN.
Will blocking the port at the firewall close the finding?
Only for the scanner you blocked. Every host that is still allowed can connect without a password, so require authentication as well.
Does a view-only server count?
Yes. The plugin checks whether None is offered, not what the viewer can do, and a screen alone can expose credentials or process values.
Should Windows servers use RDP instead?
If VNC exists only for Windows server administration, removing it leaves one less remote access service to maintain. Our RDP hardening guide covers the replacement.
Tracking this finding across many hosts
Open VNC tends to return when a vendor installs it for a support session or a panel is replaced. A platform such as SITEY can import Nessus results (as an uploaded .nessus export) alongside other scanners, draft a host-specific fix that its agents deploy on Windows and Linux endpoints only after human approval, and re-test each Nessus finding to confirm plugin 26925 has closed.