CVE-2026-53916: 
Apache ActiveMQ Classic vulnerability analysis and mitigation

CVE-2026-53916 is a Memory Allocation with Excessive Size Value (CWE-789) vulnerability in Apache ActiveMQ's STOMP NIO codec, commonly referred to as "Unbounded header buffer in STOMP NIO codec." An unauthenticated remote client can open a STOMP NIO connection and send header bytes that never terminate, causing the broker to buffer them indefinitely and exhaust the JVM heap. Affected products include Apache ActiveMQ, Apache ActiveMQ All, and Apache ActiveMQ Stomp — all versions before 5.19.8, and versions 6.0.0 through before 6.2.7. The vulnerability was disclosed on June 29, 2026, by Christopher L. Shannon of the Apache Software Foundation, with credit to researcher "tonghuaroot" as the finder. It carries a CVSS v3.1 base score of 7.5 (High) (Apache Advisory, GitHub Advisory, oss-security).

The root cause is classified as CWE-789 (Memory Allocation with Excessive Size Value): the STOMP NIO codec in Apache ActiveMQ does not enforce any upper bound on the amount of header data it buffers from an incoming connection. An attacker establishes a STOMP NIO connection and continuously streams header bytes without ever sending a terminating newline or frame delimiter, causing the broker's internal buffer to grow without limit until JVM heap memory is exhausted. No authentication, privileges, or user interaction are required — the attack is purely network-based with low complexity. No public proof-of-concept code has been identified at this time (Apache Advisory, oss-security, Red Hat Bugzilla).

Successful exploitation results in a Denial of Service (DoS) against the Apache ActiveMQ broker: the JVM heap is exhausted, causing the broker to crash or become completely unresponsive, disrupting all message queuing and brokering operations. There is no impact on confidentiality or data integrity — the attack is purely an availability concern. In environments where ActiveMQ serves as a critical messaging backbone, broker unavailability can cascade to dependent applications and services (GitHub Advisory, Apache Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible Apache ActiveMQ brokers running vulnerable versions (before 5.19.8 or 6.0.0–6.2.6) using tools like Shodan, Censys, or Nmap targeting the default STOMP port (61613).
2. Establish STOMP NIO connection: Open a raw TCP connection to the broker's STOMP NIO listener port (typically 61613).
3. Send non-terminating header bytes: Transmit a continuous stream of STOMP frame header bytes (e.g., a CONNECT frame header) without ever sending the required line terminator (\n) or null byte frame delimiter, preventing the codec from completing header parsing.
4. Sustain the connection: Keep the connection open and continue sending data to force the broker to accumulate buffered bytes indefinitely.
5. Exhaust JVM heap: As the broker buffers the unbounded header data, JVM heap memory is progressively consumed until an OutOfMemoryError is thrown, crashing or hanging the broker process and denying service to all legitimate clients (oss-security, Apache Advisory).

• Network: Persistent, long-lived TCP connections to the ActiveMQ STOMP port (default 61613) from unexpected or external IP addresses that never complete a valid STOMP handshake; high volume of inbound data on the STOMP port with no corresponding outbound responses.
• Logs: ActiveMQ broker logs showing OutOfMemoryError or JVM heap exhaustion errors; repeated or sustained connection attempts from a single source IP on the STOMP NIO listener; absence of completed STOMP CONNECT/CONNECTED frame exchanges in transport logs.
• Process: ActiveMQ JVM process exhibiting rapidly increasing heap usage (observable via JMX, JVisualVM, or jstat); broker process crash or restart events correlated with unusual STOMP connection activity.
• System: Sudden broker unavailability or unresponsiveness; JVM garbage collection logs showing continuous full GC cycles with no heap reclamation prior to crash (oss-security, Red Hat Bugzilla).

Apache has released patched versions 5.19.8 and 6.2.7, which enforce bounds on STOMP NIO header buffering; upgrading to one of these versions is the primary recommended remediation (Apache Advisory). As a network-level workaround, restrict access to the STOMP port (default 61613) using firewall rules or network ACLs to allow only trusted, authenticated clients, reducing exposure to unauthenticated attackers. No official configuration-only workaround (short of disabling STOMP entirely) has been published by Apache (Red Hat Bugzilla).

The vulnerability was disclosed via the Apache security mailing list and oss-security on June 29, 2026, by Christopher L. Shannon, crediting "tonghuaroot" as the finder (oss-security). Red Hat opened a tracking bug (Bugzilla #2494846) and assigned it high severity, with 57 CC'd users indicating broad internal attention across Red Hat product teams (Red Hat Bugzilla). Security news outlets such as SecurityOnline.info covered the vulnerability alongside related Apache ActiveMQ advisories, and it was noted on social platforms including Bluesky within hours of disclosure.