CVE-2026-53916

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-53916) has been identified in the STOMP NIO transport of Apache ActiveMQ Classic, which allows unauthenticated attackers to exhaust the broker's JVM heap by sending STOMP frame headers that never terminate.

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:activemq-stomp, org.apache.activemq:activemq-all, org.apache.activemq:apache-activemq
• 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-stomp, https://central.sonatype.com/artifact/org.apache.activemq/activemq-all, https://central.sonatype.com/artifact/org.apache.activemq/apache-activemq
• 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-stomp package in multiple versions of Apache ActiveMQ Classic. The STOMP NIO transports (stomp+nio and stomp+nio+ssl) decode incoming bytes with StompCodec.parse(). While the codec is still reading a frame's command and header lines, it appends every byte to an in-memory ByteArrayOutputStream named currentCommand and only inspects the buffer to see whether the blank line that ends the header section has arrived:

if (!processedHeaders) {
    ...
    currentCommand.write(b);
    // end of headers section, parse action and header
    if (b == '\n' && (previousByte == '\n' || currentCommand.endsWith(crlfcrlf))) {
        DataByteArrayInputStream data = new DataByteArrayInputStream(currentCommand.toByteArray());
        ...
    }
}

Size limits are only applied after the header block is complete: wireFormat.parseAction() and wireFormat.parseHeaders() enforce per-line length and header-count limits on that block and add its size to a running frame size, which is compared with the configured maxFrameSize only in parseContentLength() and in the body branch of the parser. No size check applies while header bytes are still accumulating. A client does not need to authenticate to reach this code, because the CONNECT frame that carries credentials is itself parsed by the same loop. An attacker can therefore open a STOMP NIO connection and stream header bytes that never contain the terminating blank line. The broker keeps growing currentCommand for each such connection until the JVM heap is exhausted, which causes OutOfMemoryError failures and denies service to every client of the broker.

‍

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

• tonghuaroot (finder)