CVE-2017-12617: Apache Tomcat Remote Code Execution Vulnerability

CVE-2017-12617 is a remote code execution vulnerability in Apache Tomcat. It allows an attacker to upload a JSP file through a specially crafted request; once that file is requested, the server executes whatever code it contains. For IT and security teams, this matters because successful abuse can give an attacker the ability to run arbitrary code in the context of the Tomcat process, potentially leading to full compromise of the host or the applications it serves.

Public detail is limited to the CISA description and the associated weakness class. Confirm exact affected versions, configurations, and fixes against the vendor advisory before acting.

How it works

The underlying weakness is CWE-434: unrestricted upload of a file with a dangerous type. In this case, Tomcat can be induced to accept and store a JSP file via a specially crafted request. Because Tomcat treats JSP files as executable server-side resources, a subsequent request for the uploaded file causes the container to compile and run the code inside it.

An attacker who can reach an endpoint that performs or permits the upload therefore gains a path to code execution without needing valid credentials or a separate exploit chain, provided the server’s configuration allows the upload and subsequent execution. Specific request formats, headers, or path tricks are not detailed in the supplied facts; treat any such mechanics as requiring verification against the official advisory and do not rely on unverified proof-of-concept details.

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, CI/CD tooling, and custom Java web applications. It often listens on HTTP/HTTPS ports and may sit behind reverse proxies or load balancers.

• Inventory: Search configuration management databases, package inventories, container images, and process lists for Tomcat installations (look for catalina, tomcat, or related service names). Check both production and non-production environments.
• Version and configuration review: Identify the exact Tomcat release and whether features that accept file uploads or allow JSP deployment are enabled. Compare the installed version and settings against the vendor advisory for CVE-2017-12617; do not assume a version is safe without that confirmation.
• Network exposure: Determine which Tomcat instances are reachable from untrusted networks or from other internal segments that an attacker might already control.
• Telemetry signs: Review access and application logs for unusual PUT/POST requests that result in new .jsp (or similarly executable) files under web application directories, followed by requests to those newly created resources. Unexpected JSP compilation activity or new files appearing in deployment directories can also be indicators. Correlate with process creation or outbound connections originating from the Tomcat user.

How to remediate

Patch first. Apply the updates provided by the Apache Tomcat project exactly as directed in the vendor advisory for CVE-2017-12617. CISA’s required action is to apply updates per vendor instructions; treat that as the primary remediation step.

• After patching, restart or redeploy affected instances according to your change process and verify the new version is running.
• Harden upload handling for this class of weakness: disable or tightly restrict any functionality that accepts arbitrary file uploads, enforce allow-lists of permitted extensions and content types, store uploaded content outside executable directories, and ensure JSP (or equivalent) execution is not possible from user-writable locations.
• Run Tomcat with least privilege, keep the process account separate from other services, and limit the directories it can write to.
• Re-scan or re-inventory after remediation to confirm no unpatched instances remain.

If you can't patch immediately

Implement compensating controls while you schedule the vendor update.

• Segmentation: Isolate Tomcat hosts from untrusted networks and from sensitive internal systems; restrict management and application ports to only necessary sources.
• Virtual patching / WAF: Deploy rules that block or challenge requests attempting to upload or invoke JSP (or other executable) content via unexpected methods or paths. Tune carefully to avoid breaking legitimate traffic and confirm rule efficacy against the advisory description.
• Disable or constrain the affected feature: If file upload or automatic JSP deployment is not required, turn it off or limit it to authenticated, authorized administrative interfaces only.
• Monitoring: Increase logging verbosity for request methods and paths that could create files, alert on creation of new JSP-like resources under web roots, and watch for anomalous process activity under the Tomcat user. Retain logs for forensic review.
• Access control: Enforce strong authentication and authorization on any administrative or deployment endpoints and remove anonymous or overly permissive write access.

These measures reduce risk but do not replace the vendor patch. Plan to apply the official update as soon as practicable.

If your data may have been exposed

Actively exploited remote-code-execution vulnerabilities can lead to broader compromise and data exposure. Known ransomware use of this CVE is not documented in the supplied facts, but that does not rule out other malicious activity. If you have reason to believe an instance was abused, follow your incident-response process: isolate affected hosts, preserve logs and disk images, rotate credentials that may have been accessible to the Tomcat process, and assess what data or systems the attacker could have reached.

You can also run a free exposure scan of your email addresses to check whether they appear in known breach data, which may help identify secondary account compromise related to any incident.