CVE-2016-8735

What Is Apache Tomcat?

Apache Tomcat is the most widely deployed open-source Java web application server, running hundreds of thousands of enterprise Java applications. Tomcat hosts Java Servlet and JSP applications for enterprises, banks, government systems, and cloud platforms globally. As a critical middleware layer for enterprise Java, Tomcat security vulnerabilities have broad impact across the Java ecosystem. Tomcat is maintained by the Apache Software Foundation and is included in many commercial Java application server products.

Java Management Extensions (JMX) is the Java platform's standard management API, used to expose application metrics, configuration, and management operations to monitoring systems and management consoles. Tomcat's JMX implementation allows remote management of Tomcat server instances over RMI (Remote Method Invocation).

Overview

CVE-2016-8735 is a remote code execution vulnerability in Apache Tomcat arising from Tomcat's JmxRemoteLifecycleListener not being updated to address the same deserialization issue fixed in Oracle Java SE's JMX implementation (CVE-2016-3427). When Tomcat is configured with JmxRemoteLifecycleListener and JMX ports are network-accessible, an unauthenticated attacker can exploit the Java JMX RMI deserialization path to execute arbitrary code on the Tomcat server. Apache patched CVE-2016-8735 across all active Tomcat branches in November 2016. CISA added it to the KEV catalog in May 2023.

Affected Versions

Important: CVE-2016-8735 only affects Tomcat instances with JmxRemoteLifecycleListener configured in server.xml and with JMX ports (RMI) reachable by the attacker.

Technical Details

Root Cause: JmxRemoteLifecycleListener Inherits Java JMX Deserialization Flaw

CVE-2016-8735 is a deserialization vulnerability (CWE-502) that exists because Apache Tomcat's JmxRemoteLifecycleListener was not updated when Oracle fixed CVE-2016-3427 in the Java JMX implementation.

Background — Java JMX and deserialization: Java JMX uses Java RMI (Remote Method Invocation) for remote management connections. RMI communications use Java serialization to pass objects between the JMX client and server. Java deserialization is inherently dangerous when the deserializing code can load untrusted data: a malformed serialized object can exploit the deserialization process to execute arbitrary code on the server during the ObjectInputStream.readObject() call.

The CVE-2016-3427 / CVE-2016-8735 relationship:

1. Oracle discovered and patched CVE-2016-3427 in Java SE's JMX implementation (April 2016 CPU) — addressing deserialization in the RMI registry component used by JMX
2. Apache Tomcat's JmxRemoteLifecycleListener uses Java's JMX/RMI infrastructure but implements its own JMX endpoint registration
3. The Tomcat listener was not updated to incorporate Oracle's fix — leaving Tomcat's JMX-over-RMI path vulnerable to the same deserialization issue even on patched JDKs
4. An attacker connecting to Tomcat's JMX RMI port (typically 8086 or configured custom port) can send a malicious serialized Java object
5. Tomcat deserializes the object, triggering code execution in the Java process with Tomcat's privileges

Exploitation requirements:

• JmxRemoteLifecycleListener must be configured in Tomcat's server.xml (not enabled by default)
• JMX RMI port must be network-accessible to the attacker
• A Java deserialization exploit payload (e.g., via ysoserial) targeting a gadget chain present in Tomcat's classpath

Attack Characteristics

Discovery

Identified by the Apache Tomcat security team during review of Oracle's CVE-2016-3427 patch for Java JMX; Apache confirmed that Tomcat's JmxRemoteLifecycleListener did not incorporate Oracle's fix and was independently vulnerable.

Exploitation Context

• JMX as a recurring Java attack surface: Java JMX/RMI deserialization is a well-established exploitation path — tools like ysoserial provide ready-made exploit payloads for dozens of gadget chains present in common Java libraries (Apache Commons Collections, Spring, Groovy); CVE-2016-8735 is exploitable using the same deserialization payloads that targeted many Java applications in 2015–2017
• JMX port exposure: Organizations frequently expose JMX management ports without authentication on internal networks or cloud infrastructure with broad security groups; JMX was historically used for monitoring without authentication requirements; port scans reveal many Tomcat instances with exposed JMX ports
• Shodan exposure: Internet-facing Tomcat JMX RMI ports are scannable and exploitable; CVE-2016-8735 affects any internet-facing Tomcat with JmxRemoteLifecycleListener and an exposed JMX port — a configuration present in older enterprise deployments
• Non-default but common configuration: While JmxRemoteLifecycleListener is not enabled by default, many enterprise Tomcat deployments enable it for operational monitoring; documentation examples showing JMX configuration led to widespread deployment of the vulnerable listener
• CISA KEV (2023): Added May 2023, reflecting continued exploitation of Java deserialization via JMX against Tomcat servers

Remediation

1. Upgrade Apache Tomcat — update to a patched version: 6.0.48, 7.0.73, 8.0.38, 8.5.6, or 9.0.0.M12 (or any later release). The patch updates JmxRemoteLifecycleListener to incorporate Oracle's CVE-2016-3427 fix.

2. Disable JmxRemoteLifecycleListener if not needed — if remote JMX management is not required, remove the JmxRemoteLifecycleListener from server.xml. This eliminates the attack surface entirely.

3. Restrict JMX port access — if JMX must remain enabled, restrict the JMX RMI port to only authorized management system IP addresses via host firewall rules or network ACLs; JMX ports must never be internet-accessible.

4. Enable JMX authentication and SSL — configure Tomcat JMX with com.sun.jndi.rmi.registry.registrySocket authentication and SSL; this prevents unauthenticated deserialization connections.

5. Use serialization filters — Java 9+ supports JEP 290 serialization filters that whitelist allowed deserialization classes; configure jdk.serialFilter or Tomcat's equivalent to restrict JMX deserialization to expected types.

6. Audit JMX exposure — scan all Tomcat instances in the environment for open JMX RMI ports: nmap -p 8086 <server-ip> or equivalent; any open JMX port should be treated as a critical finding requiring immediate remediation.