How to Fix SQL Server Browser UDP 1434 Exposure (Nessus 10674)

Microsoft SQL Server UDP Query Remote Version Disclosure (Nessus plugin 10674) means the SQL Server Browser service answers unauthenticated queries on UDP 1434 with the server name, instance names, version and connection ports. Fix it by blocking UDP 1434 at the firewall and, when no client needs instance name resolution, stopping and disabling the SQL Server Browser service.

The finding is informational. The real work is finding which applications still connect by instance name, because those connections break when SQL Server Browser on UDP 1434 goes away.

What the scanner is actually detecting

This is an exposure check, not a missing patch. Nessus queries the SQL Server instance mapping port on UDP and reports that the host answered.

The listener is the SQL Server Browser service (service name SQLBrowser, program sqlbrowser.exe). It claims UDP 1434 at startup, reads the registry to find every instance on the computer, and tells clients which TCP port or named pipe each one uses. By default, setup starts it automatically when you install a named instance (including every SQL Server Express installation), install on a cluster, or upgrade.

Per Microsoft’s SQL Server Resolution Protocol specification, the reply describes each instance with ServerName, InstanceName, IsClustered, Version and, when enabled, tcp (the TCP port) and np (the named pipe). Tenable’s description warns that the version value stopped being updated after 8.00.194, so do not treat it as the instance’s patch level.

Real-world risk

On its own this is reconnaissance, not compromise. Anyone who can send a one-byte UDP request learns where every instance listens, including named instances on dynamic ports. That shortens the path to password guessing or to an unpatched instance, but the attacker still needs credentials or a separate vulnerability.

UDP 1434 also has history. In 2002, bulletin MS02-039 fixed buffer overruns in the SQL Server 2000 Resolution Service on this port, the flaw the SQL Slammer worm later used, and Microsoft’s mitigation was to block UDP 1434 at the firewall where feasible. Current Browser versions are not affected by that bulletin, but the advice to limit who can reach the port still applies.

Internal exposure to the application servers that use named instances is normal and often required. Exposure to the internet, or to user networks with no reason to talk to SQL Server, is what you should fix. If you are unsure what your perimeter exposes, review it as part of your external attack surface management scope.

How to confirm it on the host

On the SQL Server host, in an elevated PowerShell session:

# Browser service state and startup type
Get-Service -Name SQLBrowser | Select-Object Name, Status, StartType

# Anything bound to UDP 1434, and which process owns it
Get-NetUDPEndpoint -LocalPort 1434 | Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id (Get-NetUDPEndpoint -LocalPort 1434).OwningProcess

# Database Engine instances on this host
Get-Service -DisplayName 'SQL Server (*'

The default instance appears as SQL Server (MSSQLSERVER) and named instances as SQL Server (<instance_name>). For each named instance, check whether it uses a dynamic or static port. This query, from Microsoft’s sys.dm_server_registry documentation, returns the instance’s network configuration:

SELECT registry_key, value_name, value_data
FROM sys.dm_server_registry
WHERE registry_key LIKE N'%SuperSocketNetLib%';

Look at the IPAll rows for TcpPort and TcpDynamicPorts, and at HideInstance. A value in TcpDynamicPorts means the port is dynamic and can change on every restart.

From another machine, Nmap’s ms-sql-info script queries the Browser on UDP 1434:

nmap -sU -p 1434 --script ms-sql-info <host>

If the Browser answers, the output lists each instance with its version, TCP port and named pipe.

How to fix it

Pick the option that matches how clients reach the host:

Step 1: give named instances a static port

Without the Browser, a dynamic port becomes an outage after the next restart. In SQL Server Configuration Manager, expand SQL Server Network Configuration, select Protocols for <instance name> and double-click TCP/IP. On the IP Addresses tab, under IPAll, delete the 0 in TCP Dynamic Ports, enter a port in TCP Port, and restart the instance promptly (the Browser advertises the new port before the engine uses it). Update connection strings to tcp:server,port or create client aliases.

Option A: restrict or block UDP 1434 with the firewall

Find existing rules that allow the port or the Browser program:

Get-NetFirewallPortFilter -Protocol UDP |
  Where-Object -Property LocalPort -EQ 1434 |
  Get-NetFirewallRule |
  Select-Object DisplayName, Enabled, Direction, Action, Profile

Get-NetFirewallApplicationFilter |
  Where-Object -Property Program -Like '*sqlbrowser.exe' |
  Get-NetFirewallRule |
  Select-Object DisplayName, Enabled, Direction, Action

If the Browser must stay, narrow each allow rule to the application subnets, for example Set-NetFirewallRule -DisplayName “<rule name>” -RemoteAddress 10.20.30.0/24. Traffic matching any allow rule is permitted, so one broad rule undoes a narrow one. If nothing needs the Browser, add an explicit block rule, which overrides allow rules:

New-NetFirewallRule -DisplayName "Block SQL Server Browser UDP 1434" -Direction Inbound -Protocol UDP -LocalPort 1434 -Action Block

Mirror this on network firewalls: deny inbound UDP 1434 at the perimeter and between segments with no reason to reach SQL Server.

Option B: disable the SQL Server Browser service

In SQL Server Configuration Manager, select SQL Server Services, open the properties of SQL Server Browser, set Start Mode to Disabled on the Service tab, and stop the service. Or in PowerShell:

Stop-Service -Name SQLBrowser
Set-Service -Name SQLBrowser -StartupType Disabled

For many servers, a Group Policy Preferences service item does the same: Computer Configuration > Preferences > Control Panel Settings > Services, service name SQLBrowser, startup Disabled, service action Stop service. Because setup configures the Browser to start automatically when you upgrade an installation or add a named instance, recheck after those changes.

Option C: hide an instance with HideInstance

To stop the Browser from advertising a particular instance, open SQL Server Network Configuration, right-click Protocols for <instance>, select Properties, and on the Flags tab set HideInstance to Yes. It applies immediately to new connections. Clients must then give the port even while the Browser runs, so use a static port. On a clustered instance or availability group name, hiding can make the cluster IsAlive check fail and take SQL Server offline unless you create aliases on all nodes. HideInstance leaves the Browser listening on UDP 1434, so use it alongside Option A or B. If you keep the Browser, run it as a low-privileged account such as Local Service, as Microsoft recommends.

How to verify the fix and rescan

• Get-Service -Name SQLBrowser shows Stopped and Disabled, and Get-NetUDPEndpoint -LocalPort 1434 returns nothing (Option B).
• Applications still connect with an explicit port, for example sqlcmd -S tcp:dbserver01,50123 -E -Q “SELECT @@SERVERNAME”.
• The Nmap command above, run from the scanner’s network, returns no Browser data.

Then rescan from the same scanner location. If a scoped rule still allows the scanner’s subnet, plugin 10674 will keep firing even though other networks are protected.

What can break and how to roll back

Microsoft lists what stops working when the Browser is not running:

• Connections to a named instance that do not specify the port or pipe.
• Components that pass serverinstance strings for other components to reconnect later.
• The dedicated administrator connection (DAC) to a named instance, or to a default instance not on TCP 1433.
• The OLAP redirector for named Analysis Services instances.
• Server enumeration in SQL Server Management Studio.

To roll back, re-enable and start the service, then remove the block rule:

Set-Service -Name SQLBrowser -StartupType Automatic
Start-Service -Name SQLBrowser
Remove-NetFirewallRule -DisplayName "Block SQL Server Browser UDP 1434"

Set HideInstance back to No if you changed it. Static ports can stay.

Common false positive reasons

Something did answer on UDP 1434, so true false positives are rare. Results that look wrong usually have one of these causes (see also our guide to vulnerability scanner false positive causes):

• The scanner sits inside the allowed scope. The finding is accurate from that vantage point; decide whether that exposure is acceptable.
• A misleading version. The reported version can be stale, as Tenable notes. Check the real build with SELECT @@VERSION.
• The wrong node or address. Every cluster node runs its own Browser, and a host with several IP addresses can be scanned on one you did not test.
• Setup changed it back. An upgrade or a new named instance set the Browser to start automatically again.
• Stale results. The last scan predates the change.

FAQ

Is Nessus plugin 10674 something I have to fix?

Tenable rates it Info. Fix it when UDP 1434 is reachable from networks that do not need it, and always when it is reachable from the internet.

Can I disable SQL Server Browser with only a default instance?

Yes, if it listens on TCP 1433 and no named Analysis Services instance on the host depends on the Browser.

Does HideInstance close the finding?

Not reliably. It hides that instance, but the Browser still listens on UDP 1434. Blocking the port or disabling the service removes the exposure.

How do I connect in SSMS once the Browser is off?

Enter the server as tcp:hostname,port instead of HOSTNAMEINSTANCE, or create an alias.

Tracking this finding across many hosts

Plugin 10674 tends to come back whenever a new named instance, or an application bundling SQL Server Express, lands on a server. SITEY, a self-hosted vulnerability management platform, imports Nessus results from uploaded .nessus exports among the 16 scanners it supports and merges duplicates within each scanner. Its AI can draft host-specific scripts for changes like the ones above, which SITEY agents run on Windows endpoints only after human approval, and it can retest the individual Nessus finding to confirm closure.

Sources

• Tenable: Microsoft SQL Server UDP Query Remote Version Disclosure (plugin 10674)
• Microsoft Learn: SQL Server Browser service (Database Engine and SSAS)
• Microsoft Learn: Hide an instance of SQL Server Database Engine
• Microsoft Learn: Configure SQL Server to listen on a specific TCP port
• Microsoft Security Bulletin MS02-039: Buffer overruns in SQL Server 2000 Resolution Service