CVE-2026-49432

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-49432) has been identified in the STOMP transport of Apache ActiveMQ Classic, which allows remote unauthenticated attackers that can reach an exposed STOMP connector to exhaust broker memory by sending a frame with a negative content-length header. On the blocking STOMP transport, the same frame instead forces abnormal exception handling and closure of the affected connection.

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

‍

Details

Module Info

• Product: Apache ActiveMQ Classic
• Affected packages: org.apache.activemq:apache-activemq, org.apache.activemq:activemq-all, org.apache.activemq:activemq-stomp
• 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/apache-activemq, https://central.sonatype.com/artifact/org.apache.activemq/activemq-all, https://central.sonatype.com/artifact/org.apache.activemq/activemq-stomp
• Package manager: Maven
• Fixed in:
  • OSS Apache ActiveMQ Classic 5.19.8, 6.2.7
  • NES for ActiveMQ 5.16.8-activemq-5.16.12

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:activemq-stomp package, which is also bundled in activemq-all and the apache-activemq distribution, in multiple versions of Apache ActiveMQ Classic. When a STOMP SEND or MESSAGE frame carries a content-length header, the broker parses it with StompWireFormat.parseContentLength. That method rejects values that are not integers and values above the maximum data length or frame size, but it never rejects a negative value:

protected int parseContentLength(String contentLength, AtomicLong frameSize) throws ProtocolException {
    int length;
    try {
        length = Integer.parseInt(contentLength.trim());
    } catch (NumberFormatException e) {
        throw new ProtocolException("Specified content-length is not a valid integer", true);
    }

    if (length > getMaxDataLength()) {
        throw new ProtocolException("The maximum data length was exceeded", true);
    }

    if (frameSize.addAndGet(length) > getMaxFrameSize()) {
        throw new ProtocolException("The maximum frame size was exceeded", true);
    }

    return length;
}

A negative length passes both upper-bound checks, and adding it to the running frame size lowers that counter instead of raising it. The NIO STOMP transport then reads the frame body in StompCodec.parse, which only treats the value -1 as "read until the null terminator". Any other value is handled as a fixed-length body:

// read desired content length
if (readLength++ == contentLength) {
    processCommand();
    readLength = 0;
} else {
    currentCommand.write(b);
}

With a content length such as -2, readLength counts up from zero and never equals the negative target, so the frame never completes. Every further byte the client sends is appended to the per-connection currentCommand buffer. The maximum data length and frame size limits are only enforced on the null-terminated path, so nothing bounds this buffer. An attacker who keeps streaming body bytes on one or more connections can grow broker heap usage until the JVM runs out of memory, denying service to every client of the broker. No authentication is needed, because the content length is parsed by the transport before the frame reaches the broker's connection and security handling. On the blocking STOMP transport, unmarshal passes the negative length to new byte[length], and the resulting exception drops the connection through abnormal transport error handling.

‍

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

• Youngjoon Kim (finder)