CVE-2017-12616

What it actually does

Specially crafted requests to a VirtualDirContext allow bypassing configured security constraints and retrieving the source code of JSP resources served by that context.

Why it matters to the business

Exposure of application source code can reveal business logic, credentials, and internal paths, enabling attackers to craft more targeted follow-on attacks and increasing the risk of data or intellectual-property loss.

How an attack unfolds

An attacker identifies a Tomcat instance using VirtualDirContext, then issues HTTP requests with crafted paths or encodings that evade the container's security checks, directly retrieving JSP source instead of compiled output.

How to fix it

Upgrade Apache Tomcat to a version later than 7.0.80; if VirtualDirContext must remain in use, apply configuration changes that enforce proper security constraints on all served resources.

How to confirm the fix worked

Inventory Tomcat versions across the environment, audit web.xml and context configurations for VirtualDirContext declarations, and re-test affected paths with representative malicious requests to confirm constraints are enforced.

Typical attack path

1. Map Tomcat deployment and confirm VirtualDirContext usage
2. Send crafted HTTP request targeting JSP resources
3. Receive and inspect disclosed JSP source code

How to detect it

Review Tomcat access and error logs for requests containing unusual path encodings or direct JSP references that bypass normal rendering; correlate with VirtualDirContext configuration changes.

What your security team should do

• Prioritize upgrade of all Tomcat 7.0.x instances to a supported release
• Disable or replace VirtualDirContext where feasible
• Add access-log monitoring for anomalous JSP and directory traversal patterns