CVE-2017-12615 is an on windows remote code execution vulnerability in Apache Tomcat. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 March 2022, which means attackers have used it in real attacks. When running Apache Tomcat on Windows with HTTP PUTs enabled, it is possible to upload a JSP file to the server via a specially crafted request.
What this vulnerability means in practice
CVE-2017-12615 is dangerous because it turns a routine web feature into a path for arbitrary server-side code execution. On Apache Tomcat running on Windows, the risk becomes especially severe when HTTP PUT is allowed, because an attacker can place executable content on the server rather than simply read data from it.
The core lesson is that the vulnerability is not just about a malformed request, it is about an unsafe combination of deployment choices. A Tomcat instance exposed to the network, configured to accept file uploads or PUT requests, and permitted to execute JSP content can become a direct remote execution target once an attacker reaches the upload path.
Why Windows deployments make the exposure worse
Windows hosting adds operational friction to remediation because teams often run Tomcat alongside other application services, shared directories, and legacy permissions. That makes it easier for an attacker to turn a single write primitive into active code execution, persistence, or lateral movement if the web root is writable and executable.
This is why exposure review should start with the actual runtime conditions, not the CVE name alone. Inventory the Tomcat instances, confirm whether they are internet-facing, and check whether PUT handling, upload endpoints, or alternate write paths are enabled on the affected service.
Where organisations are still triaging the vulnerability, the vendor advisory and the NIST National Vulnerability Database are the right places to verify authoritative record details, while the CVE Program provides the canonical identifier and record structure.
How organisations should assess exposure and reduce attack surface
Exposure assessment should focus on three questions: is Tomcat present, is it reachable by untrusted users, and can that service write executable content into a location the server will later run? If the answer is yes to all three, the environment should be treated as high risk even before any exploit is observed.
Compensating controls matter when patching or configuration change is delayed. Disable HTTP PUT unless it is explicitly required, remove write access from the web root, separate upload storage from executable content, and restrict access to administration and deployment paths. These measures reduce the chance that an uploaded file becomes active server-side code.
For broader vulnerability handling, the Vulnerability Management Guide is useful for prioritising KEV-listed issues, while ASP.NET machine key attacks 2025 shows how exposed server-side execution paths can turn a single secret or write primitive into full compromise.
Detection, compromise review, and recovery steps
Detection should look for suspicious PUT requests, unexpected JSP creation, and unusual child processes launched by the Tomcat service account or hosting process. File integrity monitoring and web access logs are especially useful because the exploit often leaves a visible write event before the first malicious execution.
After remediation, review for post-exploitation activity rather than assuming the system is clean once the vulnerable version is fixed. Look for newly created webshells, abnormal scheduled tasks, altered startup files, and any signs that the attacker used the initial code execution to harvest credentials or stage another payload.
If compromise is confirmed or suspected, rotate any secrets, service credentials, or deployment material that the Tomcat instance could reach. The State of NHI & AI Agent Breach Report 2026 is a strong reminder that once remote code execution exists, attackers often pivot quickly from the initial foothold to credentials and other identity material.
Risk and Threat Considerations
This vulnerability is especially attractive to attackers because it converts a simple HTTP request into server-side code execution on a widely deployed application server. Once that happens, the attacker may be able to steal data, plant a webshell, or use the compromised host as a foothold for deeper intrusion.
Failure mechanism: The flaw is exploited when a Tomcat deployment on Windows accepts PUT requests and allows uploaded JSP content to land in an executable path, so the server later runs attacker-controlled code.
Impact: A successful exploit can lead to full application compromise, persistence on the host, and follow-on credential theft or lateral movement if the attacker uses the server as a launch point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Guides secure handling of vulnerable application software and exposed web services. |
| Recommendation — Harden and patch exposed application servers, then remove unnecessary write and execution paths. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | CVE exploitation hinges on timely remediation and reduction of known software flaws. |
| AC-3 — Access Enforcement | The exploit depends on whether the server can write and execute attacker-supplied content. | |
| AU-2 — Event Logging | Detection depends on preserving logs for PUT requests, file creation, and execution events. | |
| Recommendation — Track the vulnerability, apply vendor remediation, and verify the fix on all affected hosts. Restrict write and execution permissions so uploaded content cannot become active code. Log web requests and file changes so suspicious upload-and-execute activity is visible. | ||
| OWASP ASVS | V5 — File Handling | The vulnerability abuses file upload and server-side file handling behavior. |
| V13 — Configuration | Safe deployment requires disabling unnecessary methods and tightening server configuration. | |
| Recommendation — Validate upload handling so user-supplied files cannot be written into executable locations. Remove unused HTTP methods and lock down server configuration before exposing the service. | ||
Practitioner Guidance
What to watch for: Treat exposed Tomcat instances as urgent when they accept HTTP PUT, host executable web content, or combine upload capability with write permission on the runtime path. Those conditions materially increase the chance that a routine web request becomes remote code execution.
Governance implication: Ownership should sit with both application and platform teams, because the fix is usually a combination of patching, configuration hardening, and web-root permission review. Where the service cannot be changed immediately, isolate it and remove unnecessary write and execution paths first.
Practitioner takeaway: In cases like this, exposure is determined by deployment reality, not the CVE title alone.