CVE-2026-50734

Overview

Apache ActiveMQ Classic is an open-source Java message broker that provides asynchronous messaging for applications. It supports JMS 1.1 and multiple wire protocols, including OpenWire, AMQP, MQTT and STOMP. Broker and client components are published as Maven artifacts under org.apache.activemq. ActiveMQ Classic is distinct from Apache ActiveMQ Artemis, which has its own broker implementation and release lines.

A denial of service vulnerability (CVE-2026-50734) has been identified in the OpenWire WireFormatInfo handling of Apache ActiveMQ Classic, which allows unauthenticated network attackers to crash the broker. A crafted WireFormatInfo frame sent during pre-authentication negotiation makes the broker attempt an allocation sized by an attacker-supplied value, which can exhaust the heap and trigger an OutOfMemoryError.

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 versions before 5.19.8 and versions 6.0.0 and greater before 6.2.7 of Apache ActiveMQ Classic.

‍

Details

Module Info

• Product: Apache ActiveMQ Classic
• Affected packages: org.apache.activemq:activemq-client, org.apache.activemq:apache-activemq, org.apache.activemq:activemq-all
• Affected versions: <5.19.8, >=6.0.0 <6.2.7
• GitHub repository: https://github.com/apache/activemq
• Published packages: https://central.sonatype.com/artifact/org.apache.activemq/activemq-client, https://central.sonatype.com/artifact/org.apache.activemq/apache-activemq, https://central.sonatype.com/artifact/org.apache.activemq/activemq-all
• Package manager: Maven
• Fixed in:
  • OSS Apache ActiveMQ Classic 5.19.8, 6.2.7
  • NES for ActiveMQ v5.16.12

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:activemq-client package in versions before 5.19.8 and versions 6.0.0 and greater before 6.2.7 of Apache ActiveMQ Classic. The apache-activemq distribution and the activemq-all bundle ship the same code.

When an OpenWire client connects, the broker reads the client's WireFormatInfo command before any authentication takes place. During negotiation, WireFormatNegotiator passes it to OpenWireFormat.renegotiateWireFormat(), whose accessors such as isCacheEnabled() lazily decode the marshalled property map:

private static final int MAX_PROPERTY_SIZE = 1024 * 4;

private Map<String, Object> unmarsallProperties(ByteSequence marshalledProperties) throws IOException {
    return MarshallingSupport.unmarshalPrimitiveMap(new DataInputStream(new ByteArrayInputStream(marshalledProperties)), MAX_PROPERTY_SIZE);
}

The only limit applied is the number of entries in the top-level map (up to 4096). Each value is decoded by MarshallingSupport.unmarshalPrimitive(), which trusts the length prefixes written by the client:

case BYTE_ARRAY_TYPE:
    value = new byte[in.readInt()];
    in.readFully((byte[])value);
    break;
...
case BIG_STRING_TYPE: {
    if (force) {
        value = readUTF8(in);
    } else {
        value = readUTF(in, in.readInt());
    }
    break;
}
case MAP_TYPE:
    value = unmarshalPrimitiveMap(in, true);
    break;
case LIST_TYPE:
    value = unmarshalPrimitiveList(in, true);
    break;

readUTF(in, length) allocates new byte[length] before reading any data, and unmarshalPrimitiveList() sizes an ArrayList from an unchecked readInt(). Nested maps and lists are decoded recursively with no depth limit. An attacker can therefore send a small WireFormatInfo frame whose property value declares a length close to Integer.MAX_VALUE. The broker tries to allocate that buffer up front, regardless of how many bytes actually follow, and the resulting OutOfMemoryError can bring down the whole broker JVM. No credentials are needed, because negotiation completes before the connection is authenticated.

‍

Mitigation

Inactive versions of Apache ActiveMQ Classic are End-of-Life and will not receive updates to address this issue. For more information, see here.

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

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

Credits

• Andrej Tomci (finder)