CVE-2017-12617 is a 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, it is possible to upload a JSP file to the server via a specially crafted request.
What this vulnerability class means in Tomcat
A tomcat remote code execution issue means an attacker can make the server run code of their choosing instead of only processing normal web requests. In this case, the danger is especially severe because the weakness is tied to a file-upload path that can be turned into server-side code execution when the application or deployment pattern allows it.
That matters because Tomcat often sits close to application logic, session data, configuration files and back-end services. Once an attacker can run code in the Tomcat process, they can usually move from the vulnerability itself to broader system compromise, depending on the account under which Tomcat runs and what the host can reach.
How exploitation typically unfolds
The core abuse pattern is simple: the attacker sends a specially crafted request that results in a JSP being written to the server, then invokes that uploaded server-side page so it executes on the host. The exact chain depends on configuration, but the security consequence is the same, attacker-controlled code executes inside the application runtime.
That makes this class of flaw more dangerous than a read-only bug or a crash. It can provide a direct execution path without needing valid application credentials first, and it may bypass normal application logic if the upload handling or request processing is exposed to the network.
Why exposure assessment matters
Checking exposure starts with a complete asset inventory, then narrowing to internet-facing Tomcat deployments and any application that permits file upload or servlet/JSP placement. Organisations should also review vendor advisories and the NIST National Vulnerability Database and CVE Program record for the authoritative vulnerability identity and references.
Because exploitation is environment-sensitive, exposure is not just a version question. Deployment choices, upload permissions, reverse proxies, and whether the server accepts JSP content in writable paths all affect whether the issue is practically exploitable.
Containment, detection, and post-compromise review
If patching cannot happen immediately, reduce exposure by removing public reachability where possible, restricting upload paths, and isolating the Tomcat host from sensitive back-end systems. Compensating controls should assume the upload-to-execution chain may already be reachable and limit what an executed payload can do next.
Detection should focus on suspicious JSP creation, unusual HTTP methods or request parameters, unexpected webshell-like files, and child processes spawned by the Tomcat runtime. After patching, review the host for persistence, modified web content, new scheduled tasks, credential theft, and signs that the attacker used the server as a foothold for lateral movement.
When compromise is confirmed or strongly suspected, rotate credentials, tokens, API keys, and service account material that the Tomcat process could access. If the application or host stores secrets locally, treat those values as exposed until proven otherwise.
Risk and Threat Considerations
This vulnerability is high impact because it converts a web-facing application flaw into server-side execution, which can quickly become full host compromise. The practical risk is not only initial access, but also persistence, secret theft, and movement into adjacent systems if Tomcat has broad local or network permissions.
Failure mechanism: The attacker leverages a request handling weakness to place executable JSP content on the server, then triggers that content so the application runtime executes attacker-controlled code.
Impact: Successful exploitation can expose application data, configuration, sessions, and credentials, and can turn the Tomcat host into a staging point for broader compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | Tomcat exposure depends on knowing where the server runs. |
| Recommendation — Maintain a current inventory of Tomcat assets and identify internet-facing instances. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Input Validation | The exploit depends on unsafe request handling and uploaded content. |
| Recommendation — Validate and constrain file upload handling to prevent executable content. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Tomcat hardening and exposed upload paths are configuration-driven. |
| Recommendation — Harden Tomcat deployments and remove writable execution paths. | ||
| OWASP ASVS | V5 File Handling — File Handling | The vulnerability class turns file upload handling into code execution. |
| Recommendation — Verify upload controls so uploaded content cannot execute on the server. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Remote code execution commonly lands in script or command execution on the host. |
| Recommendation — Map suspicious Tomcat execution to T1059 and hunt for spawned processes. | ||
Practitioner Guidance
Why practitioners should care: For a KEV-listed RCE in a widely deployed application server, speed of exposure reduction matters as much as patch speed. Treat the asset as actively targeted until you have confirmed that the affected surface is either removed from reach or remediated.
What to watch for: Focus on any Tomcat instance that accepts uploads, serves writable web roots, or is reachable from untrusted networks. Those are the environments where a seemingly narrow server bug can become an immediate execution path.