Web Server Unconfigured – Default Install Page Present: How to Fix (Nessus 11422)

Web Server Unconfigured – Default Install Page Present is a Nessus finding (plugin 11422) raised when a web service answers with the stock welcome page of IIS, Apache httpd, nginx or Tomcat. Fix it by uninstalling the web server if nobody uses it, or by disabling the default site and serving real content or an explicit catch-all response.

What the scanner is actually detecting

Plugin 11422 (www_default_page.nasl, family Web Servers) is a remote, unauthenticated check. It runs on every port that service detection identified as HTTP, requests the site, and fires when the response is a vendor’s default welcome page. Tenable rates it Info with no CVSS score. The plugin text says the server is either not configured or improperly configured, that it is probably unused or serving content meant to stay hidden, and its only solution is to disable the service if you do not use it.

The page depends on the product and its packager:

How serious is it?

On its own, not very. A welcome page contains no exploit path, and the Info rating is fair. It does disclose the product, and in Tomcat’s case the exact version.

The real value of the finding is what it says about ownership. A web server still showing its install page was usually pulled in as a dependency, left over from a test, or stood up outside change control, which is how shadow IT reaches production. Nobody configured it, so nobody is likely patching it, reading its logs, or watching the other default content that came with it (Tomcat’s own documentation says the examples application should always be removed from security sensitive installations). Treat 11422 as a pointer to an unknown or unowned asset, not as an emergency.

How to confirm it on the host

From a machine outside the server, request the root by IP address and by each real hostname, on every port in the finding:

curl -si http://10.0.0.15/ | head -n 20
curl -sik https://10.0.0.15/ | grep -io '<title>.*</title>'
curl -si -H "Host: www.example.com" http://10.0.0.15/ | head -n 20
nmap -p 80,443,8080,8443 --script http-title 10.0.0.15

If the IP returns the welcome page but the hostname returns your application, the server is in use and only its default virtual host is unconfigured, which changes the fix.

On the host itself, find which site or server block answers:

# IIS (elevated PowerShell)
Import-Module WebAdministration
Get-Website
Test-Path "$env:SystemDriveinetpubwwwrootiisstart.htm"

# Apache (use apache2ctl on Debian and Ubuntu)
sudo apachectl -S
ls -l /etc/httpd/conf.d/welcome.conf /var/www/html/ 2>/dev/null

# nginx: dump the loaded config and look for the default server
sudo nginx -T | grep -nE 'listen|server_name|root'

# Tomcat
ls "$CATALINA_BASE/webapps"

How to fix it

First ask whether anyone needs a web server on this host. If not, remove it. On Windows Server, Uninstall-WindowsFeature -Name Web-Server -IncludeManagementTools removes IIS and its role services (reboot if prompted). On Linux, stop and disable the service, then remove the package, for example sudo systemctl disable --now httpd followed by sudo dnf remove httpd, or the apache2, nginx or Tomcat equivalent. This is the fix Tenable recommends, and it removes every other web finding on that port too.

If the server is needed, remove the default content:

IIS

Back up the configuration first:

%windir%system32inetsrvappcmd.exe add backup before-11422

Default Web Site is unused (your applications run in other sites): stop it and keep it from starting at boot, or remove it.

%windir%system32inetsrvappcmd.exe stop site "Default Web Site"
%windir%system32inetsrvappcmd.exe set site "Default Web Site" /serverAutoStart:false

# or, in PowerShell with the WebAdministration module
Remove-Website -Name "Default Web Site"

Default Web Site hosts applications in sub paths (Exchange Server, for example, publishes its virtual directories there): keep the site and remove only the start page. Move the iisstart.* files out of wwwroot, drop the entry from the server level default document list, and put a real page or redirect at the root:

New-Item -ItemType Directory C:iis-removed -Force
Move-Item "$env:SystemDriveinetpubwwwrootiisstart.*" C:iis-removed
%windir%system32inetsrvappcmd.exe set config /section:defaultDocument /-files.[value='iisstart.htm']

Apache httpd on Debian and Ubuntu

If the host serves real virtual hosts, disable the packaged default site:

sudo a2dissite 000-default
sudo apache2ctl configtest && sudo systemctl reload apache2

Apache sends requests that match no virtual host to the first one enabled, so requests by IP will now land on your first real site. If that is not acceptable, keep 000-default and replace /var/www/html/index.html with a minimal page. Do not just delete it: apache2.conf grants Options Indexes on /var/www/, so an empty root becomes a directory listing. The package installs its default page only on a fresh install, so your replacement survives upgrades.

Apache httpd on Fedora, RHEL, Rocky and AlmaLinux

The welcome page is shown only when the DocumentRoot has no index.html, so deploying real content fixes it. Otherwise, comment out every line of welcome.conf. Do not delete the file: its own header warns that a removed copy is restored on upgrade.

sudo sed -i 's/^([^#])/#1/' /etc/httpd/conf.d/welcome.conf

The stock <Directory "/var/www/html"> block also sets Options Indexes FollowSymLinks. Change it to Options FollowSymLinks or add a minimal index page, then run sudo apachectl configtest && sudo systemctl reload httpd.

nginx

When no server block matches the Host header, nginx uses the default server for that port, which is the first one defined unless another carries default_server. Replace the stock default with an explicit catch-all that serves nothing:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

# nginx 1.19.4 or later, for HTTPS
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

Code 444 closes the connection without a response. Placement:

• Debian and Ubuntu: remove the symlink with sudo rm /etc/nginx/sites-enabled/default and save the catch-all as /etc/nginx/conf.d/catchall.conf. Deleting /var/www/html/index.nginx-debian.html alone does not stick, because the package recreates it on upgrade.
• Fedora and RHEL family: the default server block lives in /etc/nginx/nginx.conf with root /usr/share/nginx/html, whose index.html links to the packaged test page. Replace that block with the catch-all or point root at real content.
• nginx.org packages: overwrite the contents of /etc/nginx/conf.d/default.conf rather than deleting the file.

sudo nginx -t && sudo systemctl reload nginx

Apache Tomcat

Tomcat’s security guide recommends removing ROOT and the documentation application from publicly reachable instances, and always removing examples. Move them out of the Host appBase ($CATALINA_BASE/webapps by default) while Tomcat is stopped. The service name varies by install:

sudo systemctl stop tomcat
sudo mkdir -p /opt/tomcat-removed-apps
sudo mv "$CATALINA_BASE"/webapps/{ROOT,docs,examples} /opt/tomcat-removed-apps/
sudo systemctl start tomcat

Move manager and host-manager too if unused. If something must answer at /, deploy your own application as ROOT.

How to verify the fix and rescan

1. Repeat the curl and nmap commands against the IP and every hostname, on every listed port.
2. Expect real content, a redirect, a 404, an empty reply (nginx 444), a rejected TLS handshake, or a refused connection. Never a stock page.
3. Test through the path the scanner uses: if it scans a load balancer address, test that address too.
4. Rescan the affected hosts with the same Nessus policy. Plugin 11422 should no longer report on those ports.

What can break and how to roll back

• Health checks. Probes that request / by IP used to get a 200 from the welcome page and now get 404, 403 or a closed connection. Point them at a real health URL first.
• Applications under Default Web Site. Removing or stopping that site on an Exchange server, or any host that publishes applications beneath it, takes those applications down. Use the start page removal path instead.
• New default virtual host. Disabling Apache’s 000-default or nginx’s default server makes another site the catch-all. Check apachectl -S or nginx -T so an internal application is not exposed by bare IP.

To roll back:

• IIS: appcmd.exe restore backup before-11422 (this briefly stops IIS), or start the site, set serverAutoStart back to true and move the files back. Before uninstalling the role, keep a copy of %windir%system32inetsrvconfigapplicationHost.config.
• Apache: sudo a2ensite 000-default, or uncomment welcome.conf, then configtest and reload.
• nginx: sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default, remove the catch-all, test and reload.
• Tomcat: stop Tomcat, move the directories back, start it.

Common false positive reasons

• Scanned by IP. The real site is served by hostname and only the default virtual host shows the stock page. The server is in use, but the catch-all fix is still worth applying.
• Wrong device. A reverse proxy, load balancer or appliance in front of the host is showing its own default page.
• Deliberate placeholder. The root is left stock because the application lives under a sub path. Replace it with a neutral page or record an exception.
• Stale result. The report predates the change, or a node was out of the pool during your test.

FAQ

Is a default install page a vulnerability?

Not by itself. Plugin 11422 is rated Info with no CVSS score. It signals that the service may be unowned and unpatched.

Is deleting iisstart.htm enough?

It clears the finding for that site. If the host does not need IIS at all, uninstalling the role is the better fix.

Will the page come back after package updates?

It can. RHEL family packages restore a deleted welcome.conf, and Debian’s nginx package recreates a missing index file. Disable configuration instead of deleting packaged files.

Does hiding the Server header fix it?

No. The plugin recognizes the page content, and a hidden banner does not answer whether anyone manages the server.

Tracking this finding across many hosts

On a large network, plugin 11422 can surface many forgotten services at once. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, with Nessus results brought in by uploading a .nessus export, and merges duplicates within each scanner. Because per-finding retest is supported for Nessus, each host can be re-tested after its default page is removed, and host-specific remediation scripts drafted by AI run through SITEY agents on Windows and Linux only after human approval.

Sources

• Tenable: Web Server Unconfigured – Default Install Page Present (plugin 11422)
• Microsoft Learn: Default Document <defaultDocument>
• Debian manual page: a2ensite, a2dissite (8)
• nginx documentation: Server names and catch-all servers
• Apache Tomcat 10.1: Security Considerations, default web applications