CVE-2016-8735 is a remote code execution vulnerability in Apache Tomcat. CISA added it to the Known Exploited Vulnerabilities catalogue on 12 May 2023, which means attackers have used it in real attacks. Apache Tomcat contains an unspecified vulnerability that allows for remote code execution if JmxRemoteLifecycleListener is used and an attacker can reach Java Management Extension (JMX) ports.
What makes this Tomcat vulnerability dangerous
CVE-2016-8735 is dangerous because remote code execution in an application server can turn a web-facing flaw into full server compromise. In Tomcat, the risk becomes especially serious when the vulnerable JMX management path is reachable, because the attacker is no longer just requesting content, they are executing code in the runtime that hosts applications.
This kind of flaw matters most when Tomcat is running exposed management functionality or sits behind weak network segmentation. For background on how CISA treats actively exploited vulnerabilities, see the NIST National Vulnerability Database and the CVE Program.
How organisations determine exposure
Exposure checks start with simple inventory questions: where is Apache Tomcat deployed, which instances expose JMX, and whether any management ports are reachable from untrusted networks. A vulnerability like this can exist in a server that is otherwise hard to spot if Tomcat is embedded in a larger application stack or hidden behind a reverse proxy.
Organisations should compare their asset inventory against vendor advisories and KEV-tracked exploitation, then confirm whether the relevant service is internet-facing or reachable through internal pivot paths. The most reliable answer comes from reconciling discovered Tomcat services, network exposure, and the vendor guidance for the exact build in use, rather than assuming that internal-only systems are safe by default.
Remediation and compensating controls
When patching is available, it should be prioritised quickly because an exploit path that reaches Tomcat code execution can often be chained into application data access, lateral movement, or further system compromise. When a patch cannot be applied immediately, the practical goal is to reduce reachability and shrink the attack surface around JMX.
That usually means restricting network access to management ports, disabling unnecessary remote management exposure, and tightening segmentation so only trusted administrative paths can reach the service. The broader vulnerability-management discipline described in the Vulnerability Management Guide applies here: identify the asset, confirm exploitability, prioritise by exposure, and verify that the compensating control actually blocks the attack path.
Detection and post-compromise review
Detection should focus on signs that Tomcat or its surrounding host behaved like an execution platform rather than a normal application server. Unexpected child processes, unusual network connections from the Tomcat host, new files in application or temporary directories, and changes to scheduled tasks or startup scripts are all worth reviewing after suspicious activity.
If exploitation is suspected, the post-patch review should include log review, integrity checks, and a search for persistence that could survive the original vulnerability being closed. The Gladinet hard-coded keys exploitation and ASP.NET machine key attacks cases are useful reminders that code execution often leads to secondary credential or configuration abuse that outlives the first intrusion.
Risk and Threat Considerations
Remote code execution in an application server is a high-impact failure mode because it can convert a vulnerability in one exposed service into control of the underlying host. When the reachable surface includes management interfaces such as JMX, the attacker may gain a direct path to execute commands, modify application behaviour, or stage follow-on compromise.
Failure mechanism: An attacker reaches the exposed management path, triggers the vulnerable Tomcat component, and uses code execution to run commands in the server context.
Impact: The compromise can expose application data, enable persistence, and create a launch point for broader movement across the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Tomcat RCE depends on unsafe server-side handling of management input and execution paths |
| AC-4 — Information Flow Enforcement | Reachable JMX access is an information-flow boundary that must be constrained | |
| CM-2 — Baseline Configuration | Exposed management services and insecure defaults are configuration risks in Tomcat deployments | |
| Recommendation — Validate all management inputs and block unsafe command execution paths. Restrict JMX and admin traffic to trusted network paths only. Harden Tomcat baselines and remove unused management exposure. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Tomcat exposure is reduced by secure baseline configuration and service hardening |
| CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation requires prioritised discovery, triage and remediation | |
| Recommendation — Harden Tomcat instances and disable unnecessary management services. Prioritise exposed Tomcat instances for rapid remediation and verification. | ||
Practitioner Guidance
Why practitioners should care: Treat Tomcat management exposure as an attack-surface issue, not just a patching issue. If JMX or similar administration paths are reachable beyond trusted admin networks, the effective risk is much higher than the product name alone suggests.
What to watch for: Prioritise systems that are internet-facing, share credentials or administration patterns across environments, or are difficult to inventory because Tomcat is embedded inside another platform. In those cases, a single overlooked instance can remain exploitable long after the broader fleet looks patched.
Related resources from NHI Mgmt Group
- How should teams respond when Apache HTTP Server has a remote code execution CVE?
- What should security teams do first when an Apache Struts file upload flaw can lead to remote code execution?
- What is the difference between a CVE that enables remote code execution and one that enables privilege escalation?
- Why do Spring Framework property binding flaws create remote code execution risk in Tomcat-based applications?