CVE-2002-2007 in Tomcat
Summary
by MITRE
The default installations of Apache Tomcat 3.2.3 and 3.2.4 allows remote attackers to obtain sensitive system information such as directory listings and web root path, via erroneous HTTP requests for Java Server Pages (JSP) in the (1) test/jsp, (2) samples/jsp and (3) examples/jsp directories, or the (4) test/realPath.jsp servlet, which leaks pathnames in error messages.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/31/2025
This vulnerability in Apache Tomcat versions 3.2.3 and 3.2.4 represents a critical information disclosure flaw that exposes sensitive system paths to remote attackers through malformed HTTP requests targeting JSP resources. The vulnerability specifically affects default installations where error handling mechanisms inadvertently reveal directory structures and filesystem paths in error messages generated by the web server. Attackers can exploit this weakness by crafting erroneous requests to JSP files located in well-known test and sample directories including test/jsp, samples/jsp, examples/jsp, and the specific test/realPath.jsp servlet. The technical implementation of this flaw stems from inadequate error message sanitization within the Tomcat container, where internal filesystem paths are directly embedded into HTTP responses without proper filtering or obfuscation. This vulnerability aligns with CWE-209, which addresses the improper handling of error messages that may reveal system information, and represents a classic case of information exposure through error handling mechanisms. The operational impact of this vulnerability extends beyond simple path disclosure as it provides attackers with crucial reconnaissance data that can be leveraged for subsequent exploitation attempts. Knowledge of the web root path and directory structure enables attackers to craft more sophisticated attacks including directory traversal, path traversal, and potentially privilege escalation attacks against the underlying system. The flaw particularly affects the test/realPath.jsp servlet which was designed for testing purposes but remained accessible in production environments, creating an attack surface that should never have been exposed to external users. This vulnerability also relates to ATT&CK technique T1212, which involves the exploitation of software vulnerabilities to gain access to system information, and demonstrates how default configurations can create dangerous exposure points in web applications. The security implications are significant because this information disclosure can be combined with other vulnerabilities to create more effective attack vectors, allowing attackers to bypass security controls that rely on path obfuscation for protection. Organizations running these vulnerable versions of Tomcat face potential compromise of their web application infrastructure, as the leaked information can be used to map the entire application structure and identify potential targets for further exploitation.
The vulnerability operates through a fundamental flaw in the error handling architecture of the Tomcat web server, where the system fails to sanitize error messages before returning them to client applications. When malformed requests are sent to the targeted JSP endpoints, the server generates error responses that contain absolute paths to the web root directory and other system locations. These paths are typically included in stack traces or error descriptions to aid developers in debugging, but they provide attackers with critical information about the system's internal structure. The affected directories test/jsp, samples/jsp, and examples/jsp are standard locations where Tomcat includes sample applications for demonstration purposes, but these paths should never have been accessible to unauthenticated users in production environments. The test/realPath.jsp servlet specifically exposes filesystem information through its design, which was intended for development testing but was not properly secured for production use. This flaw represents a failure in the principle of least privilege, where default installations include unnecessary test components that expose system information without proper access controls. The vulnerability is particularly concerning because it affects versions that were widely deployed in production environments, meaning that many organizations were unknowingly exposing sensitive system information to potential attackers. The paths revealed through this vulnerability can include the complete installation directory structure, which allows attackers to understand how the application is organized and potentially identify other vulnerable components within the system. Security practitioners should note that this vulnerability demonstrates the importance of proper configuration management and the necessity of removing or securing test components in production deployments. The lack of input validation and output sanitization in error handling code creates a persistent threat that can be exploited repeatedly without requiring additional authentication or complex attack chains. Organizations should consider this vulnerability as part of a broader security posture assessment, as it indicates potential gaps in their overall security configuration and monitoring practices. The vulnerability also highlights the need for regular security assessments of default installations and the importance of implementing proper security hardening procedures to prevent information disclosure through error handling mechanisms. This flaw serves as a reminder that even seemingly benign error handling code can create significant security risks when not properly implemented with security considerations in mind.