Critical Activemq CVEs
13 CVEs, 2 exploited, 13 protected by Waratek
Overview 13 matches · 2 exploited · 2 CISA KEV · 5 public PoC · 5 EPSS ≥ 0.5
Protected by Waratek
13
100.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
blocked by ARMR today
13
100.0%
partly blocked
0
0.0%
not blocked
0
0.0%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 5 / year
20162
Protected by Waratek2
Critical2
blocked by ARMR today2
Exploited1
Proof of concept only1
20172
Protected by Waratek2
Critical2
blocked by ARMR today2
No public exploit2
20180
20191
Protected by Waratek1
Critical1
blocked by ARMR today1
Working exploit published1
20201
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
20215
Protected by Waratek5
Critical5
blocked by ARMR today5
Working exploit published1
Forecast only1
No public exploit3
20220
20231
Protected by Waratek1
Critical1
blocked by ARMR today1
Exploited1
20240
20250
20261
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
20162017201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-40860 | Critical | 2026-04-27 | Protected by Waratek | No public exploit | JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extends SjmsEndpoint) and through camel-amqp (whose AMQPJmsBinding extends JmsBinding), and by other JMS-family components built on JmsComponent such as camel-activemq and camel-activemq6. This issue affects Apache Camel: from 3.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.7. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2. |
| CVE-2023-46604 | Critical | 2023-10-27 | Protected by Waratek | Exploited | The Java OpenWire protocol marshaller is vulnerable to Remote Code Execution. This vulnerability may allow a remote attacker with network access to either a Java-based OpenWire broker or client to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause either the client or the broker (respectively) to instantiate any class on the classpath. Users are recommended to upgrade both brokers and clients to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3 which fixes this issue. |
| CVE-2021-21350 | Critical | 2021-03-23 | Protected by Waratek | No public exploit | XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to execute arbitrary code only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. |
| CVE-2021-21347 | Critical | 2021-03-23 | Protected by Waratek | No public exploit | XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. |
| CVE-2021-21345 | Critical | 2021-03-23 | Protected by Waratek | Working exploit published | XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker who has sufficient rights to execute commands of the host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. |
| CVE-2021-21344 | Critical | 2021-03-23 | Protected by Waratek | Forecast only | XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. |
| CVE-2021-21342 | Critical | 2021-03-23 | Protected by Waratek | No public exploit | XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability where the processed stream at unmarshalling time contains type information to recreate the formerly written objects. XStream creates therefore new instances based on these type information. An attacker can manipulate the processed input stream and replace or inject objects, that result in a server-side forgery request. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. |
| CVE-2020-11998 | Critical | 2020-09-10 | Protected by Waratek | No public exploit | A regression has been introduced in the commit preventing JMX re-bind. By passing an empty environment map to RMIConnectorServer, instead of the map that contains the authentication credentials, it leaves ActiveMQ open to the following attack: https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html "A remote client could create a javax.management.loading.MLet MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code." Mitigation: Upgrade to Apache ActiveMQ 5.15.13 |
| CVE-2013-7285 | Critical | 2019-05-15 | Protected by Waratek | Working exploit published | Xstream API versions up to 1.4.6 and version 1.4.10, if the security framework has not been initialized, may allow a remote attacker to run arbitrary shell commands by manipulating the processed input stream when unmarshaling XML or any supported format. e.g. JSON. |
| CVE-2014-3600 | Critical | 2017-10-27 | Protected by Waratek | No public exploit | XML external entity (XXE) vulnerability in Apache ActiveMQ 5.x before 5.10.1 allows remote consumers to have unspecified impact via vectors involving an XPath based selector when dequeuing XML messages. |
| CVE-2014-3579 | Critical | 2017-10-27 | Protected by Waratek | No public exploit | XML external entity (XXE) vulnerability in Apache ActiveMQ Apollo 1.x before 1.7.1 allows remote consumers to have unspecified impact via vectors involving an XPath based selector when dequeuing XML messages. |
| CVE-2016-3088 | Critical | 2016-06-01 | Protected by Waratek | Exploited | The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows remote attackers to upload and execute arbitrary files via an HTTP PUT followed by an HTTP MOVE request. |
| CVE-2015-5254 | Critical | 2016-01-08 | Protected by Waratek | Proof of concept only | Apache ActiveMQ 5.x before 5.13.0 does not restrict the classes that can be serialized in the broker, which allows remote attackers to execute arbitrary code via a crafted serialized Java Message Service (JMS) ObjectMessage object. |