In sol commit 373d848 (2024-12-12), the broker does not fully release resources when handling malformed or duplicate CONNECT packets. When clients send invalid CONNECT packets - either due to repeated attempts or failed authentication - the server may silently drop the connection or send a CONNACK but fail to close the session or deallocate internal resources. This behavior allows an attacker to create numerous half-open connections that consume memory and file descriptors indefinitely, potentially triggering the Linux OOM killer and causing a denial of service.
In Apache ActiveMQ Artemis prior to 2.20.0 or 2.19.1, an attacker could partially disrupt availability (DoS) through uncontrolled resource consumption of memory.
Apache ActiveMQ Artemis allows access to diagnostic information and controls through MBeans, which are also exposed through the authenticated Jolokia endpoint. Before version 2.29.0, this also included the Log4J2 MBean. This MBean is not meant for exposure to non-administrative users. This could eventually allow an authenticated attacker to write arbitrary files to the filesystem and indirectly achieve RCE.
Users are recommended to upgrade to version 2.29.0 or later, which fixes the issue.
While investigating ARTEMIS-2964 it was found that the creation of advisory messages in the OpenWire protocol head of Apache ActiveMQ Artemis 2.15.0 bypassed policy based access control for the entire session. Production of advisory messages was not subject to access control in error.
A class implementing the Serializable interface is free to implement the “readObject(java.io.ObjectInputStream in)” method however it chooses. This readObject method is used during the deserialization process, when constructing a java object from a serialized byte stream. It is possible to implement the method in such a way that can result in java code being executed during the deserialization of an object of this class (gadget class).
The JMS specification outlines a getObject() method on the javax.jms.ObjectMessage class. The Apache Artemis implementation of this method allows deserialization of objects, from untrusted input. There are several places where Apache Artemis uses this getObject() method. In the JMS Core client, the Artemis broker and the Artemis REST component. These Artemis components may therefore be vulnerable to a remote code execution attack. Successful exploitations of this vulnerability rely on these "gadget classes" being present on the Artemis classpath and the sender of the untrusted input being authenticated and authorized to send messages to the Artemis broker.
An issue was found in the Artemis and HornetQ .When 3rd party tool send multicast messages to Artemis/HornetQ which is configured with UDP Disovery and JGroups Discovery, Artemis/HornetQ creates a huge byte array at receiving the unexpected multicast message. So, it results in heap memory exhaustion, full GC and OutOfMemoryError in the worst case.
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.