CVE-2015-5174

What it actually does

The vulnerability permits remote authenticated users to bypass SecurityManager restrictions via directory traversal sequences (/../) in getResource, getResourceAsStream, or getResourcePaths calls, enabling listing of parent directories outside intended web application boundaries.

Why it matters to the business

Organizations running affected Tomcat versions face risk of unauthorized exposure of server directory structures and application paths, which can aid attackers in reconnaissance and subsequent targeted attacks on legacy deployments still in use.

How an attack unfolds

An attacker first obtains valid application credentials, then submits crafted resource requests containing /.. sequences to a vulnerable web application, bypassing path restrictions to enumerate parent directories such as the Tomcat base webapps folder.

How to fix it

Upgrade Apache Tomcat to version 6.0.45 or later, 7.0.65 or later, or 8.0.27 or later; disable or restrict use of getResource calls where possible and enforce strict path validation in web applications.

How to confirm the fix worked

Verify installed Tomcat version against the fixed releases; test by attempting authenticated resource requests containing /.. sequences and confirm they are blocked or sanitized.

Typical attack path

1. Obtain authenticated session to a web application hosted on vulnerable Tomcat
2. Identify endpoints or code paths invoking getResource family methods
3. Craft and submit requests embedding /.. traversal sequences in resource pathnames
4. Receive directory listings revealing parent paths and file structures
5. Use enumerated information to plan further attacks against exposed resources

How to detect it

Examine Tomcat access and application logs for authenticated requests to resource methods that contain /.. sequences or attempts to access paths outside the web application root.

• GET requests containing /.. in resource paths
• access log entries referencing getResource with parent directory traversal

What your security team should do

• Prioritize upgrade of any remaining Tomcat 6.x, 7.x, or 8.x instances below the fixed versions
• Review web application code for direct use of getResource methods and add input sanitization
• Monitor access logs for anomalous resource requests containing traversal patterns
• Apply least-privilege SecurityManager policies and audit directory permissions