Is your Tomcat Manager open to the internet? (It's one upload from a shell)

Apache Tomcat ships with a web app called the Manager. It does exactly what the name says: it lets you deploy, undeploy, start, and stop web applications through your browser, no SSH, no redeploy pipeline. For an internal admin that's convenient. On the public internet it's one of the most dangerous doors you can leave standing, because "deploy a web application" is a polite way of saying "run arbitrary code on this server."

Request /manager/html on a Tomcat host and watch the response. A locked-down server returns a 403, or nothing at all. An exposed one answers with a 401 and a header that gives the game away: WWW-Authenticate: Basic realm="Tomcat Manager Application". That realm string is emitted by exactly one thing - the Manager webapp - so seeing it means the management console is present and listening, waiting for a username and password.

Why a login page is still a critical finding

A 401 means it's asking for credentials, so surely it's safe? Not quite. The Manager is a magnet for two attacks that don't need you to do anything clever.

The first is default and weak credentials. Tomcat's tomcat-users.xml ships commented-out, but a startling number of installs add back tomcat/tomcat, admin/admin, or manager/manager to get the console working and never change them. Bots spray those combinations at every /manager/html they find. The second is that once any valid login works, the Manager's intended feature is the exploit: you upload a .war file - a packaged Java web app - and Tomcat deploys and runs it. An attacker's .war is a web shell. There's no vulnerability to patch here; the deploy button working as designed is the remote code execution.

Take it off the public internet

The Manager is an operations tool, not a public endpoint, so the fix is to make sure the public can't reach it - and, separately, that whoever can reach it has to prove who they are.

<!-- context.xml inside the Manager app: no IP restriction -->
<Context privileged="true" antiResourceLocking="false" />
<!-- tomcat-users.xml -->
<user username="tomcat" password="tomcat" roles="manager-gui"/>

The strongest move is to not deploy the Manager app in production at all - most teams deploy through CI and never touch it. If you do need it, bind it behind a RemoteAddrValve allowlist or a VPN so the internet can't reach /manager/html, and give it a long, unique password. Treat default credentials as already-breached and rotate them.

Whether your Manager answers an anonymous request from outside is something a stranger checks by sending one GET and reading the response header - which means we can check it the same way. SurfaceCheckr requests /manager/html from outside, with no credentials, and flags the finding only when the response carries the exact Basic realm="Tomcat Manager Application" header that confirms the console is live and internet-facing. It reads that header and stops there; it never tries a password or uploads anything. That's the ten-second check that your deploy console isn't sitting on the open internet.