Is CVE-2016-8735 (Apache Tomcat Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2016-8735 to its Known Exploited Vulnerabilities catalogue on 12 May 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. 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 “being exploited in the wild” means for this CVE

For this question, the key point is not whether the flaw exists, but whether it has crossed from theoretical exposure into active attacker use. CISA’s KEV listing is the strongest practical signal for that distinction, because it is reserved for vulnerabilities with reliable evidence of exploitation. The Apache Tomcat issue therefore deserves treatment as an active response item, not a routine backlog item.

That changes how teams should interpret exposure. If your Tomcat deployment uses the affected JMX-related path, the question is no longer “is this worth tracking?” but “can an attacker reach it, and can they already use it?” CISA’s KEV catalogue is the right starting point for confirming that the issue is treated as exploited, while the vendor advisory remains the authoritative source for product-specific remediation details.

How to confirm whether your environment is actually exposed

The practical exposure check is narrow: identify whether Apache Tomcat is deployed, whether the vulnerable configuration is present, and whether Java Management Extension ports are reachable from any untrusted network. Remote code execution in this case depends on that reachable management path, so the network question matters as much as the software version question.

If the service is internet-facing, assume the blast radius is larger until proven otherwise. If JMX is only reachable internally, verify whether that internal access is still broad enough for a compromised workstation, server, or adjacent application to reach it. A flaw like this often becomes exploitable because an organisation leaves an administrative interface reachable from more places than intended.

For current status and authoritative tracking, use the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database entry alongside the Apache Tomcat advisory. That combination gives you active-exploitation status, identification context, and the vendor’s remediation path.

What to do when patching or upgrade work must wait

When immediate remediation is not possible, treat containment as a temporary control, not a substitute. Reduce or remove access to the JMX ports, restrict reachability to trusted administrative paths only, and place the Tomcat instance behind stronger network controls if you cannot remediate at once. If the vulnerable management interface is not needed, disabling it is often the fastest risk reduction step.

Because this is an RCE condition, the response should also include compromise-aware validation. Review Tomcat and host logs for unexpected administrative activity, unfamiliar process launches, outbound connections, or new persistence mechanisms. If an attacker reached the management interface before remediation, credential changes alone may not be enough, because code execution can expose more than one trust boundary.

For a structured response playbook on exploited vulnerabilities, the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide both help with triage, emergency mitigation, and post-patch verification. They are especially useful when you need to separate emergency containment from longer-term remediation tracking.

Risk and Threat Considerations

Actively exploited RCE flaws matter because they compress the time between disclosure, scanning, and compromise. Once a vulnerable service is reachable, attackers can use it for initial access, command execution, and follow-on persistence before normal patch cycles complete. That is why a KEV listing should be treated as an operational escalation signal, not just a vulnerability catalog entry.

Failure mechanism: The risk arises when a reachable JMX management path allows unauthorised remote code execution through the Tomcat configuration described in the advisory, giving an attacker code-level control over the application host.

Impact: Successful exploitation can lead to application takeover, credential theft, lateral movement, and persistence on the underlying server, especially if the Tomcat instance has access to sensitive services or internal networks.

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-7 — Continuous Vulnerability Management	Tracks exploited CVEs and drives rapid remediation of known exposed systems.
Recommendation — Prioritise remediation of KEV-listed vulnerabilities on exposed systems first.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Supports identifying and tracking the Tomcat exposure and validating remediation status.
	SC-7 — Boundary Protection	JMX reachability is the key exposure factor, so boundary controls materially affect exploitability.
	SI-2 — Flaw Remediation	An actively exploited RCE requires timely remediation and exception handling.
Recommendation — Scan for the Tomcat condition and verify remediation before returning the host to service. Restrict JMX reachability to trusted administrative paths and block unnecessary access. Apply the vendor fix or approved mitigation as quickly as possible.
OWASP ASVS	V15 — Secure Coding and Architecture	Remote code execution via an exposed management interface reflects an architectural trust-boundary failure.
Recommendation — Remove unnecessary management exposure from the deployment architecture.

Practitioner Guidance

What to verify: Confirm whether JMX is exposed at all, whether it is reachable from non-administrative networks, and whether any compensating controls actually reduce that reachability. If you cannot answer those three questions quickly, you do not yet have a trustworthy exposure assessment.

Decision rule: If the Tomcat instance is reachable through the vulnerable path, prioritise containment and remediation over broad hunting first. If the instance is not reachable, document the network assumption and continue with verification, because configuration drift can reopen the path later.

What practitioners underestimate: Teams often focus on the CVE record and miss the management-plane assumption behind it. For this type of flaw, reachability and privilege context are what determine whether the vulnerability is merely present or operationally exploitable.

Practitioner takeaway: When CISA marks a flaw as actively exploited, the right response is to prove whether the vulnerable path is reachable, not to wait for signs of abuse before acting.