CVE-2026-57822

Overview

Apache ActiveMQ Artemis is an open-source, high-performance message broker and the next-generation broker of the Apache ActiveMQ project. It provides asynchronous messaging with a non-blocking, journal-backed core and supports multiple wire protocols and APIs, including AMQP 1.0, MQTT, STOMP, OpenWire, and Jakarta Messaging (JMS). Broker and client components are published as Maven artifacts under org.apache.activemq through 2.44.0 and under org.apache.artemis from 2.50.0.

A denial of service (DoS) vulnerability (CVE-2026-57822) has been identified in the message-based management handling of Apache ActiveMQ Artemis, which allows an authenticated client with MANAGE permission to send a crafted management request whose parameters are Java-deserialized, consuming excessive CPU and pinning the broker's processing thread.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects multiple versions of Apache ActiveMQ Artemis.

‍

Details

Module Info

• Product: Apache ActiveMQ Artemis
• Affected packages: org.apache.activemq:artemis-core-client, org.apache.artemis:artemis-core-client
• Affected versions:
  • org.apache.activemq:artemis-core-client: >=1.3.0 <=2.44.0
  • org.apache.artemis:artemis-core-client: >=2.50.0 <=2.56.0
• GitHub repository: https://github.com/apache/artemis
• Published packages:
  • https://central.sonatype.com/artifact/org.apache.activemq/artemis-core-client
  • https://central.sonatype.com/artifact/org.apache.artemis/artemis-core-client
• Package manager: Maven
• Fixed in:
  • OSS Apache ActiveMQ Artemis 2.57.0
  • NES for Apache ActiveMQ Artemis v2.19.5

Vulnerability Info

This Medium-severity vulnerability is found in the artemis-core-client package in multiple versions of Apache ActiveMQ Artemis. Clients can invoke broker management operations by sending a message to the management address, with the operation name in a message property and the operation parameters as a JSON array in the message body. The broker's ManagementServiceImpl.handleMessage parses these parameters through ManagementHelper.retrieveOperationParameters before it invokes the operation:

public static Object[] retrieveOperationParameters(final Message message) throws Exception {
   SimpleString sstring = message.toCore().getReadOnlyBodyBuffer().readNullableSimpleString();
   String jsonString = (sstring == null) ? null : sstring.toString();

   if (jsonString != null) {
      JsonArray jsonArray = JsonUtil.readJsonArray(jsonString);

      return JsonUtil.fromJsonArray(jsonArray);
   } else {
      return null;
   }
}

JsonUtil.fromJsonArray walks every JSON object in the array. When a key equals javax.management.openmbean.CompositeData, each value under it is treated as a Base64 string, decoded, and passed to Java deserialization:

if (CompositeData.class.getName().equals(key)) {
   Object[] data = (Object[]) innerVal;
   CompositeData[] cds = new CompositeData[data.length];
   for (int i1 = 0; i1 < data.length; i1++) {
      String dataConverted = convertJsonValue(data[i1], String.class).toString();
      try (ObjectInputStreamWithClassLoader ois = new ObjectInputStreamWithClassLoader(new ByteArrayInputStream(Base64.decode(dataConverted)))) {
         ois.setWhiteList("java.util,java.lang,javax.management");
         cds[i1] = (CompositeDataSupport) ois.readObject();
      }
   }
   innerVal = cds;
}

No management operation invoked over messaging needs these deserialized values, yet the conversion runs for any request that carries such a key. The only restriction is a package-level allow-list covering all of java.util, java.lang and javax.management, with no limit on object graph depth or size. These packages contain types whose deserialization can be made arbitrarily expensive, for example deeply nested collection objects. A client authorized for management-via-messaging can therefore send a small payload that keeps readObject() running and consuming CPU for a very long time. The work happens on the thread that processes the management message, so that thread stays pinned, denying service. The parameters are deserialized before the operation is looked up or invoked, so the payload is processed whatever operation the request names.

‍

Mitigation

Only recent versions of Apache ActiveMQ Artemis are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade Apache ActiveMQ Artemis to a currently supported release that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Clebert Suconic (finder)
• Mike Read (reporter)