CVE-2017-12615: Apache Tomcat on Windows Remote Code Execution Vulnerability

CVE-2017-12615 is a remote code execution vulnerability in Apache Tomcat when it runs on Windows with HTTP PUT support enabled. An attacker who can reach the service may upload a JSP file through a crafted request; once that file is present, a subsequent request can cause the server to execute whatever code the JSP contains. Because the flaw has been used by ransomware operators, organizations running Tomcat on Windows should treat it as a high-priority exposure until they confirm they are not vulnerable or have applied the vendor fix.

How it works

The underlying weakness is CWE-434: unrestricted upload of a file with a dangerous type. In the configuration described by CISA, Tomcat on Windows accepts HTTP PUT requests that allow an attacker to place a JSP file on the server. Because JSP files are executed by the Tomcat container when requested, the uploaded content becomes runnable code under the privileges of the Tomcat process. No further authentication details or exploit mechanics are supplied in the public summary; defenders should treat any unauthenticated or weakly authenticated PUT capability on a Windows Tomcat instance as the attack surface and confirm exact preconditions against the vendor advisory.

Am I affected? How to find it in your systems

Apache Tomcat is commonly deployed as a standalone servlet container or embedded in application servers, often fronting Java web applications on Windows hosts in both on-premises and cloud environments. Inventory every Windows system that runs a Tomcat process or service, including development, test, and forgotten instances. Check whether HTTP PUT is enabled in the relevant connector or web-application configuration; the CISA summary ties exploitation to PUT being available. Compare installed Tomcat versions and configurations against the vendor advisory for this CVE, because exact affected ranges are not restated here. Review access and application logs for unexpected PUT requests, especially those targeting paths that end in .jsp or similar extensions, and for subsequent GET requests to newly created JSP resources. Endpoint or network telemetry that shows unusual file creation under the Tomcat web root followed by code execution under the Tomcat service account is also worth investigating.

• Enumerate Windows hosts with Tomcat installed or listening on typical HTTP/HTTPS ports.
• Inspect server.xml, web.xml, and any custom valves or filters for PUT-related settings.
• Search logs for PUT methods and newly deployed JSP files outside normal release processes.
• Confirm version and patch status directly against the Apache Tomcat security advisory.

How to remediate

Apply the updates published by the Apache Tomcat project for this vulnerability, following the vendor instructions referenced in the CISA required action. After patching, verify that the fixed version is running and that PUT-based upload paths no longer allow JSP placement. As hardening for this class of flaw, disable HTTP PUT (and other non-essential HTTP methods) unless a documented business need exists, restrict the web application’s writable directories, and ensure the Tomcat process runs with least privilege so that even a successful upload cannot easily escalate. Re-scan or re-inventory after remediation to confirm no residual vulnerable instances remain.

If you can't patch immediately

Until the vendor update can be applied, reduce exposure with compensating controls. Segment Tomcat hosts so they are unreachable from untrusted networks; place them behind reverse proxies or WAFs that can block or alert on PUT requests and on attempts to access newly uploaded JSP resources. If PUT is not required, disable it at the connector or application level as a temporary virtual patch. Increase monitoring for the log and file-creation indicators described earlier, and alert on any execution of JSP files that were not part of an approved deployment. These steps do not eliminate the vulnerability but shrink the window an attacker has to abuse it.

If your data may have been exposed

Actively exploited vulnerabilities, including those known to be used by ransomware, frequently lead to broader compromise and data theft. If you discover evidence of exploitation or cannot rule out that a vulnerable Tomcat instance was reachable, treat the incident as a potential breach: isolate affected hosts, preserve logs, and begin your incident-response process. As one additional check, you can run a free exposure scan of your email addresses against known breach data sets to see whether credentials or other information tied to your organization have already appeared in public dumps.