CVE-2020-11998: Apache ActiveMQ RCE Vulnerability

CVE-2020-11998 Overview

CVE-2020-11998 is a critical vulnerability in Apache ActiveMQ 5.15.12 caused by a regression in the commit intended to prevent Java Management Extensions (JMX) re-bind attacks. The fix passed an empty environment map to RMIConnectorServer instead of the map containing authentication credentials. This leaves the JMX endpoint unauthenticated, allowing remote clients to interact with the broker's management interface. An attacker can create a javax.management.loading.MLet MBean and use it to load arbitrary MBeans from attacker-controlled URLs. When no Java security manager is configured, this results in arbitrary code execution on the host running ActiveMQ.

Critical Impact

Unauthenticated remote attackers can execute arbitrary Java code on vulnerable ActiveMQ brokers by abusing the exposed JMX interface to load malicious MBeans.

Affected Products

• Apache ActiveMQ 5.15.12
• Oracle Communications Diameter Signaling Router, Element Manager, Session Report Manager, and Session Route Manager
• Oracle Enterprise Repository 11.1.1.7.0 and Oracle FLEXCUBE Private Banking 12.0.0 / 12.1.0

Discovery Timeline

• 2020-09-10 - CVE-2020-11998 published to the National Vulnerability Database (NVD)
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-11998

Vulnerability Analysis

Apache ActiveMQ exposes a JMX-based management interface over Remote Method Invocation (RMI). A prior fix attempted to harden this interface against re-bind attacks by enforcing authentication via the environment map passed to RMIConnectorServer. The regression introduced in version 5.15.12 replaced that authenticated map with an empty environment map. The change disables credential checks on the JMX connector while still leaving the RMI registry reachable. Any client that can connect to the JMX port can register MBeans and invoke management operations without supplying credentials.

Root Cause

The root cause is an incorrect parameter passed to the RMIConnectorServer constructor inside the JMX bootstrapping path. The empty Map replaces the structure that previously held jmx.remote.authenticator and credential entries. Without those entries, the connector accepts any incoming JMX session. The vulnerability is tracked under [CWE-NVD-noinfo] in the NVD record because the upstream advisory does not map it to a more specific weakness class.

Attack Vector

An unauthenticated attacker reaches the JMX RMI port over the network. The attacker creates a javax.management.loading.MLet MBean and points it at an attacker-hosted MLet text file. The MLet loader downloads the referenced JAR and registers attacker-supplied MBeans inside the running JVM. Invoking a method on the loaded MBean executes arbitrary Java code with the privileges of the ActiveMQ broker process. Refer to the Apache ActiveMQ CVE-2020-11998 Advisory and the Oracle MLet documentation referenced in the advisory for the protocol-level details.

Detection Methods for CVE-2020-11998

Indicators of Compromise

• Outbound HTTP or HTTPS requests from the ActiveMQ broker JVM to unfamiliar hosts retrieving .mlet text files or arbitrary JAR archives.
• New child processes spawned by the ActiveMQ JVM, particularly shells, curl, wget, or scripting interpreters.
• Unexpected MBeans registered under the broker's MBeanServer, especially classes derived from javax.management.loading.MLet.
• Inbound RMI traffic to the JMX port from non-administrative source addresses.

Detection Strategies

• Inventory ActiveMQ deployments and flag any host running version 5.15.12, which is the only Apache release affected.
• Inspect broker startup arguments and configuration for the absence of com.sun.management.jmxremote.authenticate=true and missing access/password files.
• Capture and review JMX RMI session logs for connections that succeed without credential exchange.
• Run authenticated vulnerability scans against affected Oracle Communications and FLEXCUBE products using vendor signatures published in the Oracle Critical Patch Updates.

Monitoring Recommendations

• Monitor the JMX RMI port for connections originating outside the management subnet and alert on any anomalous source.
• Forward JVM and broker logs to a centralized analytics platform and correlate MBean registration events with outbound network activity.
• Track process lineage from the ActiveMQ JVM to identify post-exploitation behavior such as reverse shells or credential dumping.

How to Mitigate CVE-2020-11998

Immediate Actions Required

• Upgrade Apache ActiveMQ to version 5.15.13 or later, which restores authentication on the JMX connector.
• Apply the relevant Oracle Critical Patch Update for Communications Diameter Signaling Router, Element Manager, Session Report Manager, Session Route Manager, Enterprise Repository, and FLEXCUBE Private Banking.
• Restrict network access to the JMX RMI port using host firewalls or network access control lists, exposing it only to trusted administrative hosts.
• Audit broker configuration to confirm that jmx.remote.authenticator and credential files are correctly defined after the upgrade.

Patch Information

Apache released the fix in ActiveMQ 5.15.13. Details are documented in the Apache ActiveMQ CVE-2020-11998 Advisory and the corresponding commit threads on the Apache commits mailing list. Oracle distributed product-specific fixes in the January 2021, April 2021, July 2021, and October 2021 Critical Patch Updates.

Workarounds

• Disable remote JMX entirely by removing com.sun.management.jmxremote.port from the broker's JVM arguments if remote management is not required.
• Bind the JMX listener to 127.0.0.1 and require administrators to connect through an SSH tunnel.
• Enforce a Java SecurityManager policy that denies createClassLoader and getClassLoader permissions, preventing MLet from loading remote classes.
• Place the broker behind a network segment that blocks inbound RMI traffic from untrusted zones until patching is complete.

# Configuration example: enforce JMX authentication and SSL in ACTIVEMQ_OPTS
export ACTIVEMQ_SUNJMX_START="-Dcom.sun.management.jmxremote.port=1099 \
  -Dcom.sun.management.jmxremote.authenticate=true \
  -Dcom.sun.management.jmxremote.ssl=true \
  -Dcom.sun.management.jmxremote.password.file=${ACTIVEMQ_CONF}/jmx.password \
  -Dcom.sun.management.jmxremote.access.file=${ACTIVEMQ_CONF}/jmx.access"

# Restrict access at the host firewall (example for iptables)
iptables -A INPUT -p tcp --dport 1099 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 1099 -j DROP