Apache Tomcat Default Files (Nessus plugin 12085) means a Tomcat server still serves its stock welcome page, documentation, example JSPs and servlets, or an error page that reveals the Tomcat version. Fix it by removing the examples, docs and default ROOT web applications, adding an ErrorReportValve with showReport and showServerInfo set to false, then restarting Tomcat and rescanning.
What the scanner is actually detecting
This is a remote, unauthenticated web check. The scanner requests well-known Tomcat paths on every HTTP port it finds and looks at what comes back. It never reads your configuration, so each Tomcat connector (8080, 8443, or a port proxied through httpd) is judged separately.
| Scanner | Finding title | ID |
|---|---|---|
| Nessus | Apache Tomcat Default Files | Plugin 12085 (Medium, CVSS v3 5.3, family Web Servers) |
According to Tenable, the plugin flags four kinds of content: default error pages, default index pages, example JSPs and example servlets. In practice that maps to the stock ROOT welcome page, the /docs/ application, the /examples/ application (with its jsp and servlets sections), and the built-in 404 page that prints the exact Tomcat release. Tenable’s recommended solution is to remove the default index pages and examples and to replace or modify the default error pages. Read the plugin output on your report, because it lists which of these items triggered on that host.
How serious is it?
Moderately low on its own. The Apache Tomcat security guide rates the ROOT and documentation applications as very low risk; their main problem is that they identify the Tomcat version. The examples application has no known vulnerabilities, but its cookie examples display and set cookies, which an attacker could combine with a flaw in another application on the same instance. The Tomcat project says the examples app “should always be removed from any security sensitive installation.”
The version string on the default error page is the more useful leak: it lets anyone match your exact release against published Tomcat CVEs without logging in. The default error handler can also show stack traces. None of this gives an attacker access by itself, but it shortens reconnaissance, and auditors treat default content as a sign that a server was never hardened. If the Manager or Host Manager is also deployed, treat that as a separate and more serious concern: Tomcat’s own documentation notes the Manager is frequently targeted because of weak passwords.
How to confirm it on the host
Start from outside the server, sending the same kind of requests the scanner sends:
H=http://tomcat.example.com:8080
for p in / /docs/ /examples/ /examples/jsp/ /examples/servlets/ /manager/html /host-manager/html; do
printf '%-22s %sn' "$p" "$(curl -s -o /dev/null -w '%{http_code}' "$H$p")"
done
# Does the error page leak the version?
curl -s "$H/no-such-page-12085" | grep -o 'Apache Tomcat/[0-9.]*'A 200 on /docs/ or /examples/ means the application is deployed. A 401 or 403 on /manager/html means the Manager exists but is protected; 404 means it is gone. Any output from the last command means the error page discloses the version.
Then check what is deployed on the server itself:
# Tarball install
ls -l "$CATALINA_BASE/webapps" "$CATALINA_BASE/conf/Catalina/localhost"
"$CATALINA_HOME/bin/version.sh"
# Debian / Ubuntu packages (tomcat9 or tomcat10)
dpkg -l 'tomcat*' | grep ^ii
ls /var/lib/tomcat10/webapps /etc/tomcat10/Catalina/localhost
# Fedora-family packages
rpm -qa 'tomcat*'
ls /var/lib/tomcat/webapps# Windows (PowerShell), adjust the path to your installation
Get-Service Tomcat*
Get-ChildItem "C:Program FilesApache Software FoundationTomcat 10.1webapps"Note the Debian detail: the docs, examples and admin packages deploy through context files such as /etc/tomcat10/Catalina/localhost/examples.xml, with the files under /usr/share/tomcat10-examples. Looking only in webapps will make you think they are not installed.
How to fix it
Step 1: remove the default web applications
Before deleting anything, confirm that your own application is not deployed as ROOT (a ROOT.war or a ROOT directory containing your code). Only the stock welcome page should be removed.
Tarball installs (Linux): stop Tomcat, archive the default apps, then remove them. Delete any matching .war file and context file in conf/Catalina/localhost too, or auto-deployment can bring the app back.
"$CATALINA_HOME/bin/shutdown.sh"
cd "$CATALINA_BASE/webapps"
sudo tar czf /root/tomcat-default-webapps.tgz examples docs ROOT
sudo rm -rf examples docs
sudo rm -rf ROOT # only if ROOT is the stock welcome page
sudo rm -rf manager host-manager # only if nobody uses them
"$CATALINA_HOME/bin/startup.sh"Debian and Ubuntu: remove the packages rather than the files (use tomcat9 names on older releases).
sudo apt purge tomcat10-examples tomcat10-docs
sudo apt purge tomcat10-admin # only if Manager and Host Manager are unused
sudo systemctl stop tomcat10
sudo mv /var/lib/tomcat10/webapps/ROOT /root/tomcat10-ROOT.bak
sudo systemctl start tomcat10Fedora-family distribution packages: the stock ROOT page ships in tomcat-webapps, the documentation in tomcat-docs-webapp, and Manager plus Host Manager in tomcat-admin-webapps.
sudo dnf remove tomcat-webapps tomcat-docs-webapp
sudo dnf remove tomcat-admin-webapps # only if unused
sudo systemctl restart tomcatWindows: the service is named after the major version (Tomcat9, Tomcat10, Tomcat11).
$tc = 'C:Program FilesApache Software FoundationTomcat 10.1'
Stop-Service Tomcat10
Compress-Archive -Path "$tcwebappsexamples","$tcwebappsdocs","$tcwebappsROOT" -DestinationPath C:Backuptomcat-default-webapps.zip
Remove-Item -Recurse -Force "$tcwebappsexamples","$tcwebappsdocs"
Remove-Item -Recurse -Force "$tcwebappsROOT" # only if ROOT is the stock welcome page
Start-Service Tomcat10Step 2: stop error pages from disclosing the version
Removing ROOT does not finish the job, because requests for missing pages are now answered by Tomcat’s built-in error handler, which prints the version by default. Add an explicit Error Report Valve inside every <Host> element in server.xml ($CATALINA_BASE/conf/server.xml, /etc/tomcat10/server.xml on Debian, /etc/tomcat/server.xml on Fedora, or confserver.xml on Windows):
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
<Valve className="org.apache.catalina.valves.ErrorReportValve"
showReport="false" showServerInfo="false" />
...
</Host>Both attributes default to true. With showServerInfo="false" the version disappears; with showReport="false" the message and stack trace disappear. With both off, Tomcat returns only the HTTP status code. If you prefer a branded page, the same valve accepts errorCode.nnn attributes pointing to static UTF-8 HTML files relative to $CATALINA_BASE, for example errorCode.404="conf/404.html". Applications can also define their own <error-page> entries in web.xml, but the valve covers requests that no application handles.
Check the syntax, then restart:
# Debian packages: export CATALINA_HOME=/usr/share/tomcat10 CATALINA_BASE=/var/lib/tomcat10
"$CATALINA_HOME/bin/catalina.sh" configtest
sudo systemctl restart tomcat10 # or your service name, or shutdown.sh + startup.shOn Windows, restart the service with Restart-Service Tomcat10.
Optionally, Tomcat’s security guide describes overriding the reported version with CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties containing a server.info= line. It also changes what management tools report, so use it only if you understand that trade-off.
Step 3: if you keep the Manager
Tenable’s description of plugin 12085 does not name the Manager, but if it stays deployed, keep its default RemoteCIDRValve in META-INF/context.xml (localhost only), give its users strong passwords in tomcat-users.xml, and grant only the manager-* roles each person or pipeline needs.
How to verify the fix and rescan
- Rerun the curl loop from the confirmation section.
/docs/and/examples/should return 404, and/should return 404 or your own application. - Rerun the version grep; it should print nothing.
curl -si "$H/no-such-page-12085"should show a bare 404 with no Tomcat branding. - Check
catalina.outorjournalctl -u tomcat10for SEVERE startup errors. - Rescan with Nessus. You can limit the policy to plugin 12085 against the affected hosts and ports to close the finding faster.
Package upgrades and fresh deployments from an old image can quietly restore default content, so keep this check in recurring scans rather than treating it as one-time work.
What can break and how to roll back
- Deleting the wrong ROOT. If your application was the ROOT context, the site goes down. Restore it from the archive.
- Health checks on
/. A load balancer probe that expects 200 on/will mark every node down once ROOT is gone. Point it at a real application URL first. - Deployment pipelines. CI jobs that deploy through
/manager/text(themanager-scriptrole) fail if you remove the Manager. Searchtomcat-users.xmlfor manager roles before removing it. - Debugging. With
showReport="false", developers no longer see stack traces in the browser. They remain in the Tomcat logs. - Typos in server.xml stop Tomcat from starting, which is why
configtestcomes before the restart.
To roll back, extract the archive back into webapps, reinstall the packages (apt install tomcat10-examples tomcat10-docs or the dnf equivalents), restore the saved server.xml, and restart Tomcat.
Common false positive reasons
- Embedded Tomcat in a vendor product. Many appliances and management consoles embed Tomcat. The finding is real, but the fix belongs to the vendor; open a case or record a risk acceptance.
- Wrong instance. One host can run several Tomcat instances with different
CATALINA_BASEdirectories and ports. Match the flagged port to the instance you changed. - Missing virtual host. The valve was added to one
<Host>, but the scanner hit another, or scanned by IP and landed on the default host. - Reverse proxy in front. httpd or a load balancer forwards to a backend Tomcat you did not touch.
- Stale results. The scan ran before the restart. More general causes are covered in our guide to why vulnerability scanners report false positives.
FAQ
Is it safe to delete the ROOT web application?
Yes, as long as it only contains the stock welcome page. Tomcat will answer / with a 404, which is fine for servers that host named application contexts.
Does showServerInfo=”false” also remove the Server header?
No. That header is controlled by the Connector’s server attribute, and Tomcat 8.5 and later do not set it by default.
Does hiding the version fix vulnerable Tomcat releases?
No. It only removes one disclosure path. An outdated Tomcat is still vulnerable and still needs patching.
Why is it still flagged on Debian after I emptied webapps?
The packaged examples and docs deploy from context files in /etc/tomcat10/Catalina/localhost. Purge the packages instead.
Tracking this finding across many hosts
Default Tomcat content tends to appear on every server built from the same image, so one finding can cover dozens of hosts and ports. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, including Nessus results uploaded as .nessus exports, and merges duplicates within each scanner. Plugin 12085 can be re-tested per finding after the change, and AI-drafted, host-specific cleanup scripts run through its agents on Windows and Linux only after human approval.