Apache ActiveMQ CVE-2026-34197 Added to CISA KEV Amid Active Exploitation

CVE-2023-46604 is a critical deserialization flaw (CWE-502) in the Java OpenWire protocol marshaller of Apache ActiveMQ that permits unauthenticated remote code execution (CVSS 9.8). An attacker with network access to either a Java-based OpenWire broker or client can manipulate serialized class types in the OpenWire protocol, causing the peer to instantiate arbitrary classes on the classpath and execute arbitrary shell commands. Successful exploitation yields full command execution on the target broker or client, with no authentication or user interaction required. Affected parties include anyone running ActiveMQ broker or Java client versions prior to 5.15.16, 5.16.7, 5.17.6, or 5.18.3, as well as NetApp E-Series products and Debian packages that ship affected ActiveMQ/OpenWire components. Exploitation is confirmed in the wild: the flaw was added to CISA's KEV on 2023-11-02 with known ransomware use (RansomHub), and has been used to drop Kinsing malware, Godzilla web shells, and the DripDropper implant, in some cases with attackers patching the flaw post-exploitation to lock out competing intruders.

Do: Upgrade all ActiveMQ brokers and Java OpenWire clients to 5.15.16, 5.16.7, 5.17.6, or 5.18.3 (or later), and apply the relevant NetApp E-Series and Debian updates for bundled components; restrict the OpenWire port (default TCP 61616) from untrusted networks. Hunt for indicators of the documented campaigns (Godzilla web shells, Kinsing malware, DripDropper, RansomHub) and verify the broker's current version, since attackers have been observed patching the flaw post-exploitation to hide from defenders. The CISA KEV listing means federal agencies must apply vendor mitigations or discontinue use of the product.

In Apache ActiveMQ 6.x, the default configuration doesn't secure the API web context (where the Jolokia JMX REST API and the Message REST API are located). It means that anyone can use these layers without any required authentication. Potentially, anyone can interact with the broker (using Jolokia JMX REST API) and/or produce/consume messages or purge/delete destinations (using the Message REST API). To mitigate, users can update the default conf/jetty.xml configuration file to add authentication requirement: Or we encourage users to upgrade to Apache ActiveMQ 6.1.2 where the default configuration has been updated with authentication by default.

Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on its web console, and the default Jolokia access policy allows authenticated users to invoke exec operations on all ActiveMQ MBeans, including BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). An authenticated attacker abuses these operations with a crafted discovery URI so that the VM transport's brokerConfig parameter loads a remote Spring XML application context; because ResourceXmlApplicationContext instantiates singleton beans before the BrokerService validates the configuration, arbitrary code runs in the broker's JVM (e.g., through Runtime.exec() bean factory methods), yielding code execution with the broker's privileges. Affected users are those running Apache ActiveMQ Broker, ActiveMQ All, or ActiveMQ (Classic) on versions before 5.19.4 or 6.x versions from 6.0.0 before 6.2.3. Authentication to the web console is required (CVSS privileges-required: low), but CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2026-04-16 amid reported active exploitation, and EPSS puts 30-day exploitation probability at 98.3%. No public proof-of-concept is known, and whether ransomware groups are using it is unknown.

Do: Upgrade Apache ActiveMQ to 5.19.4 (5.x line) or 6.2.3 (6.x line), which fix the issue; federal agencies must apply mitigations under BOD 22-01 timelines. As interim mitigation, restrict access to the web console /api/jolokia/ endpoint, tighten the Jolokia access policy so exec is not permitted on org.apache.activemq:* MBeans (especially BrokerService.addNetworkConnector/addConnector), and enforce strong authentication. Review broker logs for Jolokia calls to these operations and for unexpected VM-transport connector additions.