Apache ActiveMQ Artemis before 2.34.0 contains an unsafe reflection vulnerability in FederationStreamConnectMessage.getFederationPolicy(). The method calls Class.forName(clazz).getConstructor().newInstance() where clazz is read directly from the CORE protocol wire buffer without type validation. An authenticated federation peer can send a FEDERATIONDOWNSTREAMCONNECT packet with a crafted class name, causing the broker to load and instantiate arbitrary classes visible to the Artemis module classloader. Static initializers (<clinit>) and no-argument constructors (<init>()) execute as side effects before the type cast, enabling denial of service via system-property poisoning, out-of-memory conditions via classloading, or broker state manipulation.
A remote attacker can craft an Openwire RemoveSubscriptionInfo command to cause the deletion of a queue on the Artemis broker before the connection authentication and authorization stage or at any time thereafter.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
Source: Internal security audit — AMQ Broker f005 Upstream project: Apache ActiveMQ Artemis Upstream advisory: None — pending report to security
Affected code: - OpenWireConnection.java — processRemoveSubscription() executes pre-auth, calls server.destroyQueue(SimpleString) with null SecurityAuth, skipping authorization check entirely
Fix status: No upstream fix available. Vulnerability confirmed in upstream versions 2.33.0, 2.40.0, 2.55.0 (latest) and downstream AMQ Broker 7.14 GA.
Upstream report: CVE-2026-57822 reserved by Apache Security. Reporter: Clebert Suconic (Apache Artemis committer) via PSIRTSUPT-18814.
Vulnerable class: org.apache.activemq.artemis.api.core.JsonUtil.fromJsonArray() Vulnerable JAR: artemis-core-client Affected versions: Artemis 2.16.0 through main (unfixed)
Attack requires MANAGE role (high-privilege administrative permission). Impact: DoS only (deserialization bomb). No RCE or data exfiltration. Allowlist (java.util,java.lang,javax.management) blocks URLDNS and all known RCE gadget chains.
Fix: Upstream plans to disallow JsonUtil from performing server-side deserialization. JsonUtil was only intended for client-side management console browsing.
Cross-reference: This is the same issue as IBM EAP report Medium Finding jboss-eap38.md.
Upstream report: CVE-2026-57822 reserved by Apache Security. Reporter: Clebert Suconic (Apache Artemis committer) via PSIRTSUPT-18814.
Vulnerable class: org.apache.activemq.artemis.api.core.JsonUtil.fromJsonArray() Vulnerable JAR: artemis-core-client Affected versions: Artemis 2.16.0 through main (unfixed)
Attack requires MANAGE role (high-privilege administrative permission). Impact: DoS only (deserialization bomb). No RCE or data exfiltration. Allowlist (java.util,java.lang,javax.management) blocks URLDNS and all known RCE gadget chains.
Fix: Upstream plans to disallow JsonUtil from performing server-side deserialization. JsonUtil was only intended for client-side management console browsing.
Cross-reference: This is the same issue as IBM EAP report Medium Finding jboss-eap38.md.
An unauthenticated network-adjacent attacker can leverage discovery to capture cluster administrative credentials during the initial cluster connection handshake.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
Affected versions:
- Apache Artemis (org.apache.artemis:artemis-server) 2.50.0 through 2.51.0 - Apache ActiveMQ Artemis (org.apache.activemq:artemis-server) 2.11.0 through 2.44.0
Description:
Missing Authentication for Critical Function (CWE-306) vulnerability in Apache Artemis, Apache ActiveMQ Artemis. An unauthenticated remote attacker can use the Core protocol to force a target broker to establish an outbound Core federation connection to an attacker-controlled rogue broker. This could potentially result in message injection into any queue and/or message exfiltration from any queue via the rogue broker. This impacts environments that allow both:
- incoming Core protocol connections from untrusted sources to the broker
- outgoing Core protocol connections from the broker to untrusted targets
This issue affects:
- Apache Artemis from 2.50.0 through 2.51.0
- Apache ActiveMQ Artemis from 2.11.0 through 2.44.0.
Users are recommended to upgrade to Apache Artemis version 2.52.0, which fixes the issue.
The issue can be mitigated by either of the following:
- Remove Core protocol support from any acceptor receiving connections from untrusted sources. Incoming Core protocol connections are supported by default via the "artemis" acceptor listening on port 61616. See the "protocols" URL parameter configured for the acceptor. An acceptor URL without this parameter supports all protocols by default, including Core.
- Use two-way SSL (i.e. certificate-based authentication) in order to force every client to present the proper SSL certificate when establishing a connection before any message protocol handshake is attempted. This will prevent unauthenticated exploitation of this vulnerability.
Credit:
Hardik Mehta <me...> (finder)
References:
https://artemis.apache.org https://www.cve.org/CVERecord?id=CVE-2026-27446
An unauthenticated remote attacker can craft a CORE protocol SESSIONREATTACH packet to steal an existing session and assume ongoing execution of the previously authenticated session.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
indepth analysis: https://docs.google.com/document/d/1XdX8AJzGjBgCLE0UZ5NRGGrzQ14HSVS8HcDgH0X70w/edit?tab=t.d440c4doqxdr#bookmark=kix.ffo7qhxjskp1
The finding correctly identifies a composite attack chain where an unauthenticated attacker exploits three independently verified weaknesses in the Artemis CORE protocol: (1) the SUBSCRIBETOPOLOGYV2 handler on channel0 leaks the broker's nodeID (a type-1 UUID) without authentication, revealing the MAC address and clock sequence embedded in the UUID; (2) cluster-bridge sessions are named using type-1 UUIDs generated by the same UUIDGenerator instance with the same MAC/clock-sequence seed, making session names predictable to within ~10,000 candidates (the number of 100ns intervals per millisecond); (3) the REATTACHSESSION handler (ActiveMQPacketHandler.handleReattachSession()) performs zero authentication — it looks up the session by name only and calls transferConnection() unconditionally, migrating the authenticated session to the attacker's connection. The hijacked cluster-bridge session inherits full broker-management authority (message injection, topology manipulation, journal access)
An unauthenticated remote attacker connecting with the CORE protocol can discover cluster node details by sending a SUBSCRIBETOPOLOGY request prior to authentication.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
Pre-auth topology disclosure via Artemis CORE SUBSCRIBETOPOLOGYV2 on channel0. CoreProtocolManager.LocalChannelHandler.handlePacket() processes topology subscriptions with zero authentication -- no getSecurityStore(), no subject validation. Contrasts with federation handler fixed via ARTEMIS-5928 (CVE-2026-27446).
Vulnerable class: org.apache.activemq.artemis.core.protocol.core.impl.CoreProtocolManager - https://github.com/apache/activemq-artemis/blob/2.16.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/CoreProtocolManager.java - https://github.com/apache/activemq-artemis/blob/2.52.0/artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/CoreProtocolManager.java
Affected: All Artemis versions (2.16.0 through 2.52.0 and main) Fixed: No upstream fix available
Related (different issue): CVE-2026-27446 (federation handler auth bypass only, fixed via ARTEMIS-5928)
A vulnerability exists in Apache Artemis whereby an application using the STOMP protocol with security credentials that grant either the consume or send permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. A user could successfully send a message to an address or consume a message from a queue with a routing-type not supported by the corresponding address when that operation should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address. Even though the user was already granted permission to send and/or consume messages, they should not be able to augment the routing-type of the address without the createAddress permission.
This issue affects Apache Artemis: from 2.50.0 through 2.53.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.54.0, which fixes the issue.
An unauthenticated remote attacker can create arbitrary durable queues via the CORE protocol, leading to unauthorized broker state manipulation and potential denial of service.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
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.
An authenticated client could attach a consumer with a selector containing crafted wildcard usage that results in excessive evaluation during message delivery attempts, occupying a shared broker thread and leading to denial of service.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes this issue.
Severity: moderate
Affected versions:
- Apache Artemis (org.apache.artemis:artemis-selector) 2.50.0 through 2.56.0 - Apache ActiveMQ Artemis (org.apache.activemq:artemis-selector) 1.0.0 through 2.44.0
Description:
An authenticated client could attach a consumer with a selector containing crafted wildcard usage that results in excessive evaluation during message delivery attempts, occupying a shared broker thread and leading to denial of service.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes this issue.
Credit:
Mike Read (finder)
References:
https://artemis.apache.org https://www.cve.org/CVERecord?id=CVE-2026-75880
Severity: important
Affected versions:
- Apache Artemis (org.apache.artemis:artemis-openwire-protocol) 2.50.0 through 2.56.0 - Apache Artemis (org.apache.artemis:artemis-jakarta-openwire-protocol) 2.50.0 through 2.56.0 - Apache ActiveMQ Artemis (org.apache.activemq:artemis-openwire-protocol) 1.0.0 through 2.44.0 - Apache ActiveMQ Artemis (org.apache.activemq:artemis-jakarta-openwire-protocol) 2.32.0 through 2.44.0
Description:
A remote attacker can craft an Openwire RemoveSubscriptionInfo command to cause the deletion of a queue on the Artemis broker before the connection authentication and authorization stage or at any time thereafter.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
Credit:
Daniel Birtwhistle (finder) krsecurity(kongr) (reporter) Dilrevx, NSSL, SJTU (reporter)
References:
https://artemis.apache.org https://www.cve.org/CVERecord?id=CVE-2026-67593
Severity: important
Affected versions:
- Apache Artemis (org.apache.artemis:artemis-server) 2.50.0 through 2.56.0 - Apache ActiveMQ Artemis (org.apache.activemq:artemis-server) 1.0.0 through 2.44.0
Description:
An unauthenticated remote attacker can craft a CORE protocol SESSIONREATTACH packet to steal an existing session and assume ongoing execution of the previously authenticated session.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
Credit:
Domenico Francesco Bruscino (finder) Fedrick Sequeira (reporter)
References:
https://artemis.apache.org https://www.cve.org/CVERecord?id=CVE-2026-57967
Severity: important
Affected versions:
- Apache Artemis (org.apache.artemis:artemis-core-client) 2.50.0 through 2.56.0 - Apache ActiveMQ Artemis (org.apache.activemq:artemis-core-client) 1.3.0 through 2.44.0
Description:
When the broker is processing message-based management requests, sent by an authenticated messaging client that is authorized with MANAGE permission to perform management-via-messaging, the parameter processing can trigger Java deserialization of certain method parameters that the broker will not utilise. The permitted types allow to craft a payload causing excessive computation and pinning the processing thread, leading to denial of service.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.3.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
Credit:
Clebert Suconic (finder) Mike Read (reporter)
References:
https://artemis.apache.org https://www.cve.org/CVERecord?id=CVE-2026-57822
Severity: moderate
Affected versions:
- Apache Artemis (org.apache.artemis:artemis-server) 2.50.0 through 2.56.0 - Apache ActiveMQ Artemis (org.apache.activemq:artemis-server) 1.0.0 through 2.44.0
Description:
An unauthenticated remote attacker connecting with the CORE protocol can discover cluster node details by sending a SUBSCRIBETOPOLOGY request prior to authentication.
This issue affects Apache Artemis: from 2.50.0 through 2.56.0; Apache ActiveMQ Artemis: from 1.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.57.0, which fixes the issue.
Credit:
Domenico Francesco Bruscino (finder)
References:
https://artemis.apache.org https://www.cve.org/CVERecord?id=CVE-2026-49363
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.
A flaw was found in AMQ Broker. This issue can cause a partial interruption to the availability of AMQ Broker via an Out of memory (OOM) condition. This flaw allows an attacker to partially disrupt availability to the broker through a sustained attack of maliciously crafted messages. The highest threat from this vulnerability is system availability.
A flaw was found in ActiveMQ Artemis management API from version 2.7.0 up until 2.12.0, where a user inadvertently stores passwords in plaintext in the Artemis shadow file (etc/artemis-users.properties file) when executing the resetUsers operation. A local attacker can use this flaw to read the contents of the Artemis shadow file.
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.
A vulnerability exists in Apache ActiveMQ Artemis whereby a user with the createDurableQueue or createNonDurableQueue permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. When combined with the send permission and automatic queue creation a user could successfully send a message with a routing-type not supported by the address when that message should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address.
This issue affects Apache ActiveMQ Artemis from 2.0.0 through 2.39.0.
Users are recommended to upgrade to version 2.40.0 which fixes the issue.
Insertion of Sensitive Information into Log File vulnerability in Apache ActiveMQ Artemis. All the values of the broker properties are logged when the org.apache.activemq.artemis.core.config.impl.ConfigurationImpl logger has the debug level enabled.
This issue affects Apache ActiveMQ Artemis: from 1.5.1 before 2.40.0. It can be mitigated by restricting log access to only trusted users.
Users are recommended to upgrade to version 2.40.0, 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.
Incorrect Authorization (CWE-863) vulnerability in Apache Artemis, Apache ActiveMQ Artemis exists when an application using the OpenWire protocol attempts to create a non-durable JMS topic subscription on an address that doesn't exist with an authenticated user which has the "createDurableQueue" permission but does not have the "createAddress" permission and address auto-creation is disabled. In this circumstance, a temporary address will be created whereas the attempt to create the non-durable subscription should instead fail since the user is not authorized to create the corresponding address. When the OpenWire connection is closed the address is removed.
This issue affects Apache Artemis: from 2.50.0 through 2.52.0; Apache ActiveMQ Artemis: from 2.0.0 through 2.44.0.
Users are recommended to upgrade to version 2.53.0, which fixes the issue.
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.