| Example | Port | Notes |
|---|---|---|
| Tomcat manager console | 8180/tcp | Default credentials, accepts WAR file deployment |
Why It Exists
Misconfiguration happens when a system is functionally set up correctly but not securely — default passwords never changed, file permissions left world-writable, or services enabled that were never actually needed. The Tomcat manager console is a clean, concrete example: Tomcat itself isn't flawed software, but shipping it with default manager credentials turns an administrative convenience into an open door.
How It's Identified
Unlike a specific software bug, misconfiguration is usually found through methodical review rather than a single scan signature:
- Checking whether management interfaces (like the Tomcat manager at
/manager/htmlon port 8180) are reachable and still using documented default credentials. - Auditing file and directory permissions for anything broader than the service actually needs.
- Comparing the full list of running services against what the system is actually supposed to do — anything unexplained is worth investigating.
Once inside the Tomcat manager with valid credentials, the manager application's own deployment feature accepts a packaged web application (a WAR file) and runs it — which is the mechanism that turns "I found default credentials" into "I can execute code," entirely through intended application functionality rather than a bug.
The Lesson
Industry breach reports consistently point to misconfiguration, not just unpatched software, as a leading root cause. It's also the category defenders have the most direct control over, since fixing it requires no vendor patch, just a deliberate review. The Tomcat example specifically illustrates a pattern that recurs constantly in real environments: an administrative or management interface, left reachable with default credentials, becomes the highest-value target on the network precisely because it's designed to let an authenticated user run code or change configuration.
How Defenders Mitigate It
Apply configuration baselines and hardening guides during initial setup, change every default credential on every management interface before it goes live, and review permissions and running services on a schedule rather than only once. Restrict administrative consoles like Tomcat's manager to trusted internal networks only, never expose them the same way as the application itself, and disable anything not actively in use.
Only interact with this service inside your own isolated Metasploitable 2 lab. Testing it against a system you don't own or have written permission to test is illegal in most jurisdictions.
Related: default credentials for the full account list, and web application vulnerabilities where Tomcat is introduced alongside the other bundled apps.
FAQ
How is this different from the vulnerabilities on the other category pages?
The other pages focus on a specific service and its own known weakness. This page is about the underlying pattern — the same kind of oversight shows up across all of them.
Is there a good way to practice reviewing configuration on Metasploitable 2?
Yes — after working through the other vulnerability categories, revisit the machine specifically looking for permissions and defaults, rather than a specific service version.
What are the default Tomcat manager credentials on Metasploitable 2?
The bundled Apache Tomcat instance on port 8180 uses default manager-console credentials of tomcat/tomcat (some builds also document admin/admin), left unchanged since installation.
Why is an exposed Tomcat manager console a serious finding?
Because the Tomcat manager application accepts deployment of new web applications (WAR files) directly, which effectively means anyone with valid manager credentials can deploy code that runs on the server.