Tomcat shutdown port 8005: the default SHUTDOWN command is an instant kill

The shutdown port is one of Tomcat’s oldest features. The stock server.xml ships with <Server port="8005" shutdown="SHUTDOWN">, which opens a raw TCP listener. Anything that can reach that port and send the bytes SHUTDOWN triggers an immediate, orderly shutdown. No authentication, no HTTP, no handshake. The string is well-known because it is the shipped default.

This is a documented feature, not a CVE. But it is a configuration risk that operators routinely misjudge. If port 8005 is reachable from an untrusted network and still carries the default command, a single netcat line stops the JVM. The mitigation is straightforward: bind the listener to localhost, replace the command with a long random string, or disable the port entirely with port="-1".

This guide covers detecting exposure and applying each mitigation, including the operational tradeoffs that catch teams off guard.

What the shutdown port is and why the default is dangerous

The <Server> element sits at the top of Tomcat’s component hierarchy. It owns the shutdown listener. When it receives a TCP connection containing a string that matches the shutdown attribute, it calls stop() on every nested component and exits the JVM.

The mechanism:

• It is a raw TCP socket, not HTTP. echo "SHUTDOWN" | nc host 8005 is all it takes.
• The address attribute controls the bind interface. If omitted, it defaults to localhost (loopback only).
• The port attribute selects the TCP port. The shipped default is 8005.
• The shutdown attribute is the trigger string. The shipped default is the literal SHUTDOWN.
• Setting port to -1 disables the listener entirely.

Orderly shutdown over a loopback socket is reasonable when you cannot rely on process signals. The danger is the combination of a guessable, publicly documented command with a listener reachable beyond the loopback. In practice, exposure usually comes from one of three places: a container or VM that publishes all ports, a server.xml copied forward from an older Tomcat that bound 0.0.0.0, or a network policy that forgot 8005 exists alongside 8080 and 8443.

Prerequisites

• Read access to $CATALINA_BASE/conf/server.xml. The path varies by distribution; Debian/Ubuntu packages use /etc/tomcat9/server.xml.
• Root or equivalent to edit server.xml and restart Tomcat.
• A test window. Changes to the <Server> element require a full JVM restart, not a hot reload.
• Knowledge of how your deployment stops Tomcat today (shell scripts vs systemd vs Commons Daemon), because disabling the port changes the stop mechanism.

Detecting exposure

Two checks. The first is network reachability, the second is the configured command.

# Check whether the shutdown port is listening and on what interface
ss -tnl 'sport = :8005'

How to read the output:

• 127.0.0.1:8005 or [::1]:8005 means loopback only. Low risk locally, but still worth hardening the command string.
• 0.0.0.0:8005 or *:8005 means all interfaces. High risk if the host is reachable from untrusted networks.
• No output means the port is either disabled (port="-1"), bound to a different port, or Tomcat is not running. Confirm against server.xml.

# Inspect the configured shutdown command and port
grep '<Server ' "$CATALINA_BASE/conf/server.xml"

Look for shutdown="SHUTDOWN". If that literal is present, the command is the well-known default regardless of bind address.

# Confirm the process matches the listener (sanity check)
pgrep -fa 'org.apache.catalina.startup.Bootstrap'

On distributions: Debian and Ubuntu Tomcat packages have shipped <Server port="-1" shutdown="SHUTDOWN"> as the default for several releases (the Debian package disabled the shutdown port starting with tomcat8 8.5.32-2, and current tomcat9 packages ship it), precisely to remove this attack surface. If you installed via apt, confirm what your distribution actually ships before assuming the upstream default applies.

Lockdown procedure

Pick one mitigation based on how you stop Tomcat. The decision tree below covers the common paths.

flowchart TD
    A["port 8005 listening?"] -->|no| OK["low risk: confirm in server.xml"]
    A -->|yes, all interfaces| RISK["high risk: network reachable"]
    A -->|yes, loopback only| MID["medium risk: default command"]
    RISK --> D{"how do you stop Tomcat?"}
    MID --> D
    D -->|systemd / jsvc / container| P1["Option A: port=-1"]
    D -->|shell scripts only| P2{"can you set CATALINA_PID?"}
    P2 -->|yes| P1
    P2 -->|no| P3["Option B + C: localhost + random string"]

Option A: disable the port entirely (port="-1")

This is the strongest fix and what DISA STIG (finding V-222951) and the CIS Tomcat benchmark require. Edit the <Server> element:

<Server port="-1" shutdown="SHUTDOWN">

The shutdown attribute value no longer matters because there is no listener.

Tradeoff: the stock shutdown.sh / catalina.sh scripts use the shutdown port to stop Tomcat. With the port disabled they cannot perform a graceful stop and the process keeps running. Two workarounds exist:

1. Run Tomcat under a service manager (systemd, Commons Daemon/jsvc, or a container runtime) and stop via that manager. systemctl stop tomcat9 sends SIGTERM, and modern Tomcat performs a clean shutdown on SIGTERM.
2. If you must use the shell scripts, set the CATALINA_PID environment variable so the scripts fall back to kill on the PID file instead of the shutdown port.

Option B: replace the command with a long random string

If you need the shutdown port for scripted stops and cannot switch to PID-based shutdown, keep the port but make the command unguessable.

<Server port="8005" shutdown="<64+ character random string>">

Generate it the usual way:

openssl rand -base64 48

This leaves the listener open, so you must also confirm it is loopback-bound (see Option C). A long random string protects against blind injection of the default command, but not against an attacker who can read server.xml.

Option C: bind to localhost explicitly

If your server.xml binds all interfaces (often the result of copying an older config), set the address attribute:

<Server port="8005" address="127.0.0.1" shutdown="<random string or SHUTDOWN>">

This is the minimum acceptable posture if you keep the port enabled. Combine with Option B for defense in depth.

Verifying the lockdown

After a full JVM restart, re-run the detection checks.

# Re-check the listener (should show nothing or loopback only)
ss -tnl 'sport = :8005'

# Re-check the config
grep '<Server ' "$CATALINA_BASE/conf/server.xml"

If you disabled the port, confirm your stop mechanism still works in a controlled maintenance window. Do not discover at the next deploy that shutdown.sh hangs.

# Verify the service manager can stop and restart Tomcat (controlled test)
systemctl stop tomcat9
systemctl start tomcat9

If you kept the port with a random command, verify the Manager or the shell script stops still function. shutdown.sh delegates to catalina.sh stop, which invokes org.apache.catalina.startup.Bootstrap stop; that reads server.xml and connects to the configured address and port (including portOffset) with the configured shutdown command. Changing the command string therefore works with the stock scripts as long as the port is enabled and reachable. With port="-1" there is no listener to connect to, and the scripts cannot stop the JVM.

Common pitfalls

Disabling the port breaks shutdown.sh on the stock distribution. The official Tomcat docs are explicit: with port="-1", the shell scripts cannot stop Tomcat gracefully. Use systemd, jsvc, a container runtime, or CATALINA_PID.

Changing the command does not require script changes. shutdown.sh delegates to catalina.sh stop, which runs Bootstrap stop and reads the configured port and shutdown command from server.xml. Changing the command string works with the stock scripts as long as the port is still enabled and reachable, so no script patching is needed. (Disabling the port is the separate case covered above.)

Assuming the listener defaults to all interfaces, or to localhost. The upstream default address is localhost, but copied-forward configs and some older packaging bind 0.0.0.0. Do not assume. Check with ss.

Forgetting 8005 in port publishing. Containers that publish all exposed ports (-P) or firewalls that allow the 8000-range can surface the shutdown port unintentionally. Explicitly publish only the ports you intend (typically 8080 and 8443).

Testing the shutdown command against production. echo "SHUTDOWN" | nc host 8005 will stop Tomcat if the command matches. Never run this against a production listener unless you are prepared for an immediate outage. Test on a staging host, or only after you have changed the command string.

Confusing a shutdown-port kill with a crash. When Tomcat is stopped via the port, it performs an orderly shutdown. If you see the JVM disappearing and the orchestrator cannot explain it, check whether port 8005 is reachable and whether the command is still the default. A shutdown-port stop looks like a clean exit, not a crash, which is exactly why it can go unnoticed.

Overlooking portOffset. Since Tomcat 9.0.16, portOffset (a <Server> attribute) shifts both the Server’s own shutdown port and the ports of nested connectors. If your server.xml uses it, the shutdown port may not be 8005. Confirm the actual listening port with ss rather than assuming the default.

Signals to monitor

How Netdata helps

• Port and process monitoring shows whether port 8005 is bound and on which interface, so a misconfigured server.xml that binds 0.0.0.0 surfaces immediately after a Tomcat restart instead of waiting for an audit.
• Per-second JVM process and uptime metrics let you correlate an unexpected Tomcat exit with external events. A shutdown-port kill produces a clean process exit that is indistinguishable from a SIGTERM unless you correlate against deploy logs and orchestrator signals.
• Anomaly detection on restart count and uptime flags unexplained JVM exits that a single “process alive” threshold would miss. That matches the pattern of an attacker probing the shutdown port or a stray script firing the old default command.
• The Tomcat collector pulls connector and thread pool metrics, so after a lockdown change and restart you can confirm the JVM came back healthy and is serving requests instead of assuming the restart succeeded.

Related guides

• Tomcat 5xx error rate: separating server failures from crawler 404s
• Tomcat accept queue overflow: acceptCount, somaxconn, and Recv-Q
• Tomcat access log setup: adding %D and %T for per-request latency
• Tomcat java.net.BindException: Address already in use: the connector never starts
• Tomcat average latency lies: why you need p95/p99 from the access log
• Tomcat threads blocked forever: the missing outbound timeout
• Tomcat classloader leak on redeploy: why the old WebappClassLoader never dies
• Tomcat connection refused: maxConnections and acceptCount both exhausted
• Tomcat accepts connections but never responds: the TCP-connect trap
• Tomcat file descriptor usage: OpenFileDescriptorCount vs the ulimit
• Tomcat frequent Full GC: pause time, G1, and the 5% overhead rule
• Tomcat GC death spiral: full GCs dominating and throughput collapsing