Apache ActiveMQ contains a deserialization of untrusted data vulnerability that may allow a remote attacker with network access to a broker to run shell commands by manipulating serialized class types in the OpenWire protocol to cause the broker to instantiate any class on the classpath.

A flaw was found in xstream. A remote attacker, who has sufficient rights, can execute commands of the host by manipulating the processed input stream. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in xstream. A remote attacker may be able to execute arbitrary code only by manipulating the processed input stream. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in xstream. A remote attacker can load and execute arbitrary code from a remote host by manipulating the processed input stream. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in xstream. A remote attacker may be able to load and execute arbitrary code from a remote host only by manipulating the processed input stream. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in xstream. A remote attacker may be able to load and execute arbitrary code from a remote host only by manipulating the processed input stream. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

It was found that XStream could deserialize arbitrary user-supplied XML content, representing objects of any type. A remote attacker able to pass XML to XStream could use this flaw to perform a variety of attacks, including remote code execution in the context of the server running the XStream application.

Apache ActiveMQ could allow a remote attacker to traverse directories on the system, caused by an error in the fileserver upload/download functionality. By placing a jsp file in the admin console, an attacker could exploit this vulnerability to execute arbitrary shell commands on the system.

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.

Apache ActiveMQ could allow a remote attacker to obtain sensitive information, caused by an XML External Entity Injection (XXE) error when processing XML data. By sending specially-crafted XML data to specify an XPath based selector, an attacker could exploit this vulnerability to obtain sensitive information.

Apache ActiveMQ could allow a remote attacker to execute arbitrary code on the system, caused by an error in the Fileserver web application. By sending a specially crafted HTTP PUT request and an HTTP MOVE request, an attacker could exploit this vulnerability to create an arbitrary file and execute arbitrary code on the system.

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 - 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

A flaw was found in xstream. An unsafe deserialization of user-supplied XML, in conjunction with relying on the default deny list, allows a remote attacker to perform a variety of attacks including a remote code execution of arbitrary code in the context of the JVM running the XStream application. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Last updated 22 August 2024

Last updated 22 August 2024

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: <bean id="securityConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">   <property name="constraint" ref="securityConstraint" />   <property name="pathSpec" value="/" /> </bean>

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 does not properly validate the remaining length field which may lead to an overflow during the decoding of malformed packets. When this integer overflow occurs, ActiveMQ may incorrectly compute the total Remaining Length and subsequently misinterpret the payload as multiple MQTT control packets which makes the broker susceptible to unexpected behavior when interacting with non-compliant clients. This behavior violates the MQTT v3.1.1 specification, which restricts Remaining Length to a maximum of 4 bytes. The scenario occurs on established connections after the authentication process. Brokers that are not enabling mqtt transport connectors are not impacted.

This issue affects Apache ActiveMQ: before 5.19.2, 6.0.0 to 6.1.8, and 6.2.0

Users are recommended to upgrade to version 5.19.2, 6.1.9, or 6.2.1, which fixes the issue.

Apache ActiveMQ contains an improper input validation vulnerability that allows for code injection.

Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ, Apache ActiveMQ Broker, Apache ActiveMQ All.

An authenticated attacker can use the admin web console page to construct a malicious broker name that bypasses name validation to include an xbean binding that can be later used by a VM transport to load a remote Spring XML application. The attacker can then use the DestinationView mbean to send a message to trigger a VM transport creation that will reference this malicious broker name which can lead to loading the malicious Spring XML context file.

Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec().

This issue affects Apache ActiveMQ: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ Broker: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ All: before 5.19.6, from 6.0.0 before 6.2.5.

Users are recommended to upgrade to version 6.2.5 or 5.19.6, which fixes the issue.

Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ.

An authenticated attacker may bypass the fix in CVE-2026-34197 by adding a connector using an HTTP Discovery transport via BrokerView.addNetworkConnector or BrokerView.addConnector through Jolokia if the activemq-http module is on the classpath. A malicious HTTP endpoint can return a VM transport through the HTTP URI which will bypass the validation added in CVE-2026-34197. The attacker can then use the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec().

This issue affects Apache ActiveMQ Broker: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ All: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ: before 5.19.6, from 6.0.0 before 6.2.5.

Users are recommended to upgrade to version 5.19.6 or 6.2.5, which fixes the issue.

Incorrect Default Permissions vulnerability in Apache ActiveMQ.

This issue affects Apache ActiveMQ: before 5.19.7, from 6.0.0 before 6.2.6.

The default Jolokia authorization settings granted non-admin (low-privilege) web-login accounts access to Jolokia operations which allowed executing broker management operations meant for admins such as addQueue and removeQueue.

Users are recommended to upgrade to version 6.2.6 or 5.19.7, which fixes the issue.

Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ.

Non-parenthesized discovery wrappers such as masterslave:vm://...,... and static:vm://... incorrectly pass validation allowing bypass of fix in CVE-2026-34197.

Original description from CVE-2026-34197.

Apache ActiveMQ exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:), including BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). An authenticated attacker can invoke these operations with a crafted discovery UR that triggers the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ Broker: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ All: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ: before 5.19.7, from 6.0.0 before 6.2.6.

Users are recommended to upgrade to version 5.19.7 or 6.2.6, which fixes the issue.

Apache ActiveMQ could allow a remote authenticated attacker to execute arbitrary code on the system, caused by an unsafe deserialization in the Jolokia component. By sending specially crafted input, an attacker could exploit this vulnerability to execute arbitrary code on the system.

Last updated 22 August 2024

Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ.

Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:), including BrokerService.addNetworkConnector(String).

An authenticated attacker can invoke these operations with a crafted discovery URI that triggers the VM transport's brokerConfig parameter using the "masterslave:// " URL which can allow loading a Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ Broker: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ All: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ: before 5.19.7, from 6.0.0 before 6.2.6.

Users are recommended to upgrade to version 5.19.7 or 6.2.6, which fixes the issue.

Improper Authorization vulnerability in Apache ActiveMQ.

An authenticated low-privilege Web Console user by default can access /admin/ paths in the Web Console. The default Jetty settings incorrectly did not limit those paths to only admins. This issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7.

Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.

A flaw was found in activemq. When anonymous binds are enabled on the LDAP provider (zero length DN/password) and the LDAP module is configured to make use of these, client credentials are not correctly verified and authentication is effectively bypassed. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Last updated 22 August 2024

Denial of Service via Out of Memory vulnerability in Apache ActiveMQ Client, Apache ActiveMQ Broker, Apache ActiveMQ.

ActiveMQ NIO SSL transports do not correctly handle TLSv1.3 handshake KeyUpdates triggered by clients. This makes it possible for a client to rapidly trigger updates which causes the broker to exhaust all its memory in the SSL engine leading to DoS.

Note: TLS versions before TLSv1.3 (such as TLSv1.2) are broken but are not vulnerable to OOM. Previous TLS versions require a full handshake renegotiation which causes a connection to hang but not OOM. This is fixed as well. This issue affects Apache ActiveMQ Client: before 5.19.4, from 6.0.0 before 6.2.4; Apache ActiveMQ Broker: before 5.19.4, from 6.0.0 before 6.2.4; Apache ActiveMQ: before 5.19.4, from 6.0.0 before 6.2.4.

Users are recommended to upgrade to version 6.2.4 or 5.19.5, which fixes the issue.

Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ Client, Apache ActiveMQ, Apache ActiveMQ All.

An unauthenticated network attacker can cause a broker DoS by sending a crafted WireFormatInfo frame with a malicious large size value. The value is not validate and causes the broker to attempt allocation during pre-auth negotiation which can trigger OOM and crash the broker. This issue affects Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7.

Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue.