Remediation Guides

How to Fix Tomcat Manager Default Credentials (Nessus 34970)

26 September 2026 8 min read

Apache Tomcat Manager Common Administrative Credentials means a scanner logged in to Tomcat’s /manager application with a well-known username and password. Fix it by deleting or re-passwording those accounts in conf/tomcat-users.xml, limiting the Manager to admin IP addresses with a Remote CIDR (or Remote Address) valve, or removing the Manager apps entirely, then restarting Tomcat.

What the scanner is actually detecting

This is a remote, unauthenticated check that ends in a real login. Once Nessus has identified Apache Tomcat on a web port, it tries a list of commonly used username and password pairs against the Manager’s HTTP Basic login and reports the finding only if one of them is accepted. It never reads your configuration files.

Scanner Finding title ID and rating
Nessus Apache Tomcat Manager Common Administrative Credentials Plugin 34970 (Critical, CVSS v3 9.8, family Web Servers)

Tenable does not publish the exact pairs the plugin tries. The plugin output in your report shows which account and URL worked, so start there. Two details from the plugin metadata matter later: it only runs when Tomcat has been detected on the host, and it is skipped when the scan policy is limited to user-supplied credentials (the global_settings/supplied_logins_only setting).

Upstream Tomcat ships with no user assigned to any Manager role, so the Manager is disabled until someone adds an account. A hit on plugin 34970 therefore always means an account was created after installation. The usual origins are a tutorial or copy-paste (Tomcat’s own Manager 401 error page shows an example user tomcat with password s3cret), an administrator account entered in the Windows installer, or a vendor product that bundles Tomcat with its own defaults.

How serious is it?

Take it seriously. Unlike a version-based finding, the scanner proved the login works. A user with the manager-gui or manager-script role can deploy a WAR file, and a WAR file is code that Tomcat runs with the rights of its service account. Tenable’s description says exactly that: an attacker could install a malicious application and run arbitrary code. Public exploit modules exist, including a Metasploit module for authenticated upload through the Manager.

The practical impact depends on two things: who can reach the port and what account Tomcat runs as. A Manager reachable from the internet is a common way into a network, which is why it belongs in any external attack surface management scope. An internal-only instance is still a direct foothold for anyone already on the network. If Tomcat runs as root or LocalSystem, the whole host is exposed, not just the application.

How to confirm it on the host

Find the instance that answered on the flagged port and its configuration directory (CATALINA_BASE):

ps -ef | grep -o 'catalina.base=[^ ]*'
sudo find / -name tomcat-users.xml -not -path '/proc/*' 2>/dev/null

Debian and Ubuntu packages keep the file in /etc/tomcat10/ (or /etc/tomcat9/); tarball installs keep it in $CATALINA_BASE/conf/. List only the users that are active. xmllint ignores commented-out entries, which a plain grep does not:

xmllint --xpath '//*[local-name()="user"]' /etc/tomcat10/tomcat-users.xml

On Windows (default installer location shown, adjust the version):

Select-String -Path "C:Program FilesApache Software FoundationTomcat 9.0conftomcat-users.xml" -Pattern '<user '
Get-Service Tomcat*

Check whether the Manager is IP-restricted. Look at webapps/manager/META-INF/context.xml and at any conf/Catalina/localhost/manager.xml. A file in conf/[enginename]/[hostname]/ always takes precedence over the one packaged in META-INF, and the Debian and Ubuntu admin packages deploy the Manager through /etc/tomcat10/Catalina/localhost/manager.xml.

Finally, reproduce the login from the scanner’s network with the pair shown in the plugin output:

curl -s -o /dev/null -w '%{http_code}n' -u 'tomcat:s3cret' http://tomcat.example.com:8080/manager/html
curl -s -u 'tomcat:s3cret' http://tomcat.example.com:8080/manager/text/list

200 (or OK - Listed applications) confirms the finding. 401 means the credentials were rejected and 403 means the valve blocked you or the user lacks the role. The LockOutRealm in the default server.xml locks a user out after 5 consecutive failures for 300 seconds, so do not loop through guesses against production.

How to fix it

1. Clean up tomcat-users.xml

Back up the file, then delete every active <user> you cannot justify, and any user whose password is a default, a dictionary word or a tutorial value. Check users holding manager-gui, manager-script, manager-jmx, manager-status and the Host Manager roles admin-gui and admin-script. Give the accounts you keep long random passwords, and follow the Tomcat recommendation never to give manager-script or manager-jmx to a user that has manager-gui:

<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<user username="tc-ops-admin" password="LONG_RANDOM_VALUE_1" roles="manager-gui"/>
<user username="tc-ci-deploy" password="LONG_RANDOM_VALUE_2" roles="manager-script"/>

Generate values with a password manager or openssl rand -base64 24. Validate the XML before restarting, because a malformed file stops the user database from loading:

xmllint --noout /etc/tomcat10/tomcat-users.xml

Optionally store hashes instead of cleartext. $CATALINA_HOME/bin/digest.sh -a SHA-512 'the-password' prints the password, a colon and the stored value; put the part after the colon in the password attribute of every user and add a credential handler to the realm in server.xml. Keep the LockOutRealm wrapper that the default server.xml already has, because it is Tomcat’s brute force protection:

<Realm className="org.apache.catalina.realm.LockOutRealm">
  <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
         resourceName="UserDatabase">
    <CredentialHandler className="org.apache.catalina.realm.MessageDigestCredentialHandler"
                       algorithm="SHA-512"/>
  </Realm>
</Realm>

2. Restrict /manager and /host-manager to admin IP addresses

Edit the context file that is actually in effect (see the precedence rule above). Current Tomcat releases ship this valve, limited to localhost; append your admin subnet:

<Valve className="org.apache.catalina.valves.RemoteCIDRValve"
       allow="127.0.0.0/8,::1/128,10.20.30.0/24" />

Older releases ship the regex-based Remote Address Valve instead. Extend its pattern, or switch to the CIDR valve, since the Tomcat documentation marks RemoteAddrValve as deprecated:

<Valve className="org.apache.catalina.valves.RemoteAddrValve"
       allow="127.d+.d+.d+|::1|0:0:0:0:0:0:0:1|10.20.30.d+" />

Apply the same change to webapps/host-manager/META-INF/context.xml (or host-manager.xml). One trap: if Apache httpd or nginx on the same machine proxies /manager to Tomcat, Tomcat sees 127.0.0.1 and the localhost rule lets everyone in. Do not proxy the Manager paths, or block them on the proxy.

3. Or remove the Manager applications

If nobody deploys through the Manager, removing it closes the finding for good. On a tarball install, stop Tomcat and move the apps out rather than deleting them, so you can roll back:

CATALINA_BASE=/opt/tomcat   # adjust
sudo systemctl stop tomcat  # adjust the unit name
sudo mkdir -p /root/tomcat-removed
sudo mv "$CATALINA_BASE/webapps/manager" "$CATALINA_BASE/webapps/host-manager" /root/tomcat-removed/
sudo systemctl start tomcat

Also move any manager.xml or host-manager.xml from conf/Catalina/localhost/. On Debian and Ubuntu, remove the package instead: sudo apt remove tomcat10-admin (tomcat9-admin on older releases). On Windows, stop the service and move webappsmanager and webappshost-manager out of the installation folder.

4. Restart Tomcat

sudo systemctl restart tomcat10   # Debian/Ubuntu package (tomcat9 on older releases)
Restart-Service Tomcat9           # Windows service (Tomcat10 or Tomcat11 on newer versions)

How to verify the fix and rescan

  1. From a machine outside the admin allow list, request /manager/html: expect 403 from the valve, or 404 if you removed the app.
  2. From an allowed admin host, repeat the old credential test with curl: expect 401.
  3. From an allowed admin host, log in with the new account to confirm legitimate access still works.
  4. Rescan with the same policy and make sure it is not limited to user-supplied credentials, otherwise plugin 34970 is skipped and the clean result proves nothing.

What can break and how to roll back

The Manager’s text interface is used by automated deployments: Jenkins jobs, Maven or Cargo deploy goals and custom scripts that call /manager/text/deploy. Changing a manager-script password or adding an IP allow list breaks them until you update their stored credentials and allow the build server’s address. Monitoring that polls /manager/status or the JMX proxy is affected the same way. Old credentials that stay in a job will also trigger the lockout realm repeatedly. Removing the Manager entirely means switching deployments to copying WAR files into webapps.

To roll back, restore the backed-up tomcat-users.xml, server.xml and context files, move the Manager directories back (or reinstall the admin package), and restart Tomcat.

Common false positive reasons

True false positives are rare because the plugin reports a successful login. Most disputes are about attribution:

  • Wrong instance. Several Tomcat instances (separate CATALINA_BASE directories) run on the host and you fixed a different one than the port in the finding.
  • Something in front. A load balancer or reverse proxy forwards the port to another backend node that still has the old account.
  • Change not loaded. The file was edited but Tomcat was not restarted.
  • Stale results. The report predates the change.
  • Bundled product. A vendor application embeds Tomcat with its own Manager defaults; the finding is real, but the fix belongs in the vendor’s configuration tooling and may be overwritten by upgrades.

FAQ

Does Apache Tomcat have a default Manager password?

No. The shipped tomcat-users.xml assigns no user to the Manager roles, so any working login was added later.

Is an IP restriction enough on its own?

No. Do both. If the scanner sits outside the allow list, the finding disappears even though the weak password is still there.

Can CI keep deploying through the Manager?

Yes. Use a dedicated manager-script account with a strong password and allow only the build server’s IP address.

Does the same fix apply to the Host Manager?

Yes. It uses the admin-gui and admin-script roles and has its own context file, so secure or remove it too.

Tracking this finding across many hosts

Weak Manager accounts tend to return when servers are rebuilt from old images or configuration templates. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results by uploading a .nessus export) and merges duplicates within each scanner, so plugin 34970 hits can be followed host by host. Nessus findings can be retested individually after the change, and AI-written, host-specific remediation scripts are deployed by its agents on Windows and Linux only after human approval, followed by a re-test to confirm closure.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles