Yes. CISA added CVE-2017-12617 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. When running Apache Tomcat, it is possible to upload a JSP file to the server via a specially crafted request.
How CISA’s KEV Listing Changes the Answer
CISA’s KEV catalogue is the practical signal that matters when you are trying to decide whether a vulnerability is just published or already being used. For CVE-2017-12617, the key question is not only whether Tomcat is affected, but whether the specific deployment exposes the upload path that makes active exploitation possible. If the vulnerable request path is reachable, treat the issue as an incident-priority exposure rather than a routine patch item.
That distinction is why practitioners should use the KEV listing as a trigger for immediate validation, not as a substitute for local exposure checks. The exploit path described in the answer, uploading a JSP file through a specially crafted request, is the kind of behaviour that can lead directly to remote code execution when the server accepts the upload.
What to Check on Apache Tomcat Systems
The first task is to confirm whether any Tomcat instance still allows the vulnerable upload behaviour and whether the relevant web applications are reachable from untrusted networks. The practical exposure question is simpler than the CVE label suggests: if an attacker can place a JSP on disk and execute it, they can often move from application access to server-side command execution.
Zero-Day and Exploited Vulnerabilities Guide is the right internal reference for triaging an actively exploited issue like this one, because it frames KEV, emergency mitigation and post-patch hunting as one workflow. For Tomcat, that means checking for exposed upload handlers, unexpected JSP artifacts and any web-root changes that were not part of a normal deployment cycle.
Confirm whether the server has been modified in ways that would make file upload abuse more likely, such as weak application-level restrictions, overly broad write permissions or inconsistent web-root separation. The most important operational point is that a vulnerable component may be present without being exploitable in practice, but once the upload path is open, exploitation becomes straightforward.
Containment, Fixing, and Looking for Pre-Existing Compromise
When a KEV-listed flaw is reachable, the response should include containment and compromise review, not just patching. If you must delay remediation, reduce exposure immediately by restricting access to the Tomcat endpoint, disabling the vulnerable upload path where possible and watching for newly created JSP files or other web-accessible payloads.
Vulnerability Management Guide supports the operational side of this response, especially verification, prioritisation and post-remediation validation. For this CVE, that means confirming the fix in the target environment, then checking for signs that the server was already used to stage files, alter web content or execute unexpected server-side code.
Because the flaw can expose a path to code execution, review logs, file timestamps and application changes for earlier compromise before you assume a clean patch has closed the issue. If you discover suspicious JSPs, unexpected child processes or post-exploitation web shells, treat the host as potentially compromised and escalate to incident response.
Risk and Threat Considerations
Actively exploited remote code execution in a web application component is high-risk because the attacker only needs one successful request path to turn a functional service into an execution foothold. The threat is not limited to the initial file upload, once code runs on the server, the attacker can often pivot into credentials, local configuration, session data or adjacent systems.
Failure mechanism: A specially crafted request is accepted by Tomcat in a way that lets the attacker upload a JSP file into a web-accessible location, then execute server-side code through that file.
Impact: The consequence can range from unauthorized command execution to full application compromise, with follow-on risk to stored secrets, service availability and lateral movement from the affected host.
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 CSF 2.0, 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-7 — Continuous Vulnerability Management | KEV-listed exploitation requires disciplined vuln prioritisation and remediation tracking. |
| Recommendation — Prioritise the Tomcat flaw for immediate remediation and verify closure before returning the host to service. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | Active exploitation calls for monitoring Tomcat logs and file changes for malicious activity. |
| Recommendation — Increase monitoring on the affected Tomcat service for upload attempts, new JSPs and suspicious execution. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue is a remediable vulnerability that needs prompt correction and validation. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-compromise checks depend on reviewing logs for exploit attempts and execution traces. | |
| Recommendation — Apply the vendor fix quickly and validate that the vulnerable upload path is no longer reachable. Review Tomcat and web-server logs for suspicious upload and execution events around the exposure window. | ||
| OWASP ASVS | V5 — File Handling | The exploit path abuses file upload handling to place executable content on the server. |
| Recommendation — Harden file upload handling so untrusted content cannot be written into executable locations. | ||
Practitioner Guidance
What to prioritise: Treat the KEV entry as a confirmation that this is a live exploitation problem, then prioritise exposure validation over backlog sorting. If the vulnerable request path is internet-facing or broadly reachable internally, it belongs ahead of routine maintenance work.
What to verify: Confirm whether the environment can accept arbitrary JSP uploads, whether any suspicious web files already exist, and whether log history shows requests consistent with upload-and-execute behaviour. If patching is delayed, verify that compensating controls genuinely block the exploit path rather than simply reducing scan noise.
Practitioner takeaway: For KEV-listed web RCE issues, the decision point is not “patch eventually”, it is whether you have already proven the host has not been used as an execution foothold.
Related resources from NHI Mgmt Group
- Is CVE-2017-12615 (Apache Tomcat on Windows Remote Code Execution) being exploited in the wild?
- How do you patch or mitigate CVE-2017-12617 (Apache Tomcat Remote Code Execution)?
- Is CVE-2016-8735 (Apache Tomcat Remote Code Execution) being exploited in the wild?
- CVE-2017-12617 (Apache Tomcat Remote Code Execution)