• Posted by: Eng. Donya Bino
• September 11, 2025

Tomcat Penetration Testing: Real-World Examples and Tips

Let me tell you about a client I worked with last year. They had a Java-based web app running on Apache Tomcat, and everything “looked fine.” But during our routine penetration test, we discovered the Manager application was exposed with default credentials. Within minutes, we could deploy a test app and simulate what an attacker could do. This was a classic case of “out of sight, out of mind”—but it could have led to serious data loss.

If you’re running Tomcat, this article is for you. We’ll cover what to look for, common vulnerabilities, and example code so you understand how attackers might try to exploit your server—and how to stop them.

Why Tomcat Needs Penetration Testing

Apache Tomcat powers thousands of Java web apps. It’s reliable, but:

1. Exposed Manager apps can let attackers upload malicious apps.
2. XML parsing can lead to XXE attacks.
3. Default credentials are surprisingly common.
4. Outdated versions have known RCE vulnerabilities.

Running a penetration test is about being proactive: finding these weak spots before a hacker does.

Common Vulnerabilities

1. Default or Weak Credentials – Especially in Manager and Host Manager apps.
2. Outdated Versions – Check for known CVEs affecting your Tomcat version.
3. XML External Entity (XXE) – If your app parses XML without protection, attackers can steal files.
4. Remote Code Execution (RCE) – Some older versions let attackers run code on the server.
5. Directory Listings & Exposed Admin Panels – Gives attackers information about your app structure.

Step-by-Step Example: Exploiting Tomcat Manager

Let’s say the Manager app is exposed at http://example.com:8080/manager/html.

1. Check for Default Credentials

Many Tomcat installations still use:

Username: admin

Password: admin

You can test this using curl (ethical, on your own server):

curl -u admin:admin http://localhost:8080/manager/html

If you get a 200 OK response, the manager is accessible.

2. Uploading a Malicious WAR File

Tomcat Manager allows you to deploy WAR files. As an attacker (or ethical tester), you might try deploying a simple test WAR:

curl -u admin:admin -T shell.war "http://localhost:8080/manager/text/deploy?path=/shell&update=true"

Once deployed, accessing http://localhost:8080/shell would execute the app—demonstrating what could happen if an attacker got in.

Note: Only do this on systems you own or are authorized to test. Never deploy malicious code on client systems without explicit permission.

3. Checking for XXE Vulnerabilities

If your web app accepts XML, test for XXE by sending a crafted payload:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE foo [

<!ENTITY xxe SYSTEM "file:///etc/passwd">

]>

<User>

  <Name>&xxe;</Name>

</User>

If the server returns the contents of /etc/passwd, it’s vulnerable—time to fix your parser settings.

How to Protect Tomcat

1. Change default credentials immediately.
2. Restrict access to Manager and Host Manager apps (IP whitelisting).
3. Keep Tomcat updated to the latest stable version.
4. Disable directory listings and remove unneeded apps.
5. Secure XML parsing to prevent XXE.
6. Run regular penetration tests to catch new vulnerabilities early.

Penetration testing Tomcat isn’t just about running tools—it’s about thinking like an attacker. Small oversights like default passwords or exposed XML parsers can be disastrous. I’ve seen companies fix issues in hours that could have taken months to recover from if exploited.

In short: test early, fix quickly, and stay ahead of attackers.