CVE-2026-53916: Apache ActiveMQ Memory Exhaustion DoS (STOMP NIO)

Technical summary

CVE-2026-53916 is a memory exhaustion vulnerability affecting the STOMP (Streaming Text Oriented Messaging Protocol) NIO (Non-blocking I/O) implementation in Apache ActiveMQ. An unauthenticated remote client can establish a connection and transmit header data with unbounded length, bypassing expected termination conditions. The broker's connection handler buffers this data without size constraints, causing unchecked heap allocation until OutOfMemoryError occurs. The vulnerability stems from improper input validation in the STOMP frame parsing logic (CWE-789: Memory Allocation with Excessive Size Value). Affected versions include all 5.x releases before 5.19.8 and 6.x releases from 6.0.0 through 6.2.6.

Business impact

Successful exploitation results in complete unavailability of the ActiveMQ broker, disrupting all message-dependent applications and workflows. Unlike attacks requiring authentication or specific network position, this vulnerability is trivially accessible to any external network client. Organizations relying on ActiveMQ for critical messaging infrastructure—such as order processing, event streaming, or inter-service communication—face operational downtime. Recovery requires manual broker restart and investigation of root cause. The low barrier to exploitation (no credentials, no special tools) elevates business risk despite the attack being limited to availability impact.

Affected systems

Apache ActiveMQ versions 5.x before 5.19.8 and 6.x from 6.0.0 through 6.2.6 are vulnerable. The issue affects the core ActiveMQ broker when STOMP protocol support is enabled (default in most deployments). Any deployment exposing the STOMP port (typically 61613) to untrusted networks is at risk. Both standalone and embedded ActiveMQ instances are affected if STOMP NIO is active.

Exploitability

This vulnerability has a high exploitability profile: no authentication is required, the network path is direct (CVSS vector AV:N), attack complexity is minimal (AC:L), and the exploit mechanics are straightforward—opening a STOMP connection and sending malformed headers. An attacker with basic networking knowledge can craft a simple script to exhaust broker memory in seconds. The lack of CVSS environmental scoring in the KEV program (currently not flagged as KEV) does not reflect the practical ease of exploitation; rather, it suggests no active wild exploitation detected at the time of advisory publication. However, simplicity of attack combined with high impact warrants immediate attention.

Remediation

Upgrade affected ActiveMQ installations to version 5.19.8 or later (5.x series) or 6.2.7 or later (6.x series). These releases include input validation fixes that enforce header size limits in the STOMP NIO parser. Verify patch deployment by checking broker version in logs or admin console. As an interim protective measure pending patching, restrict network access to the STOMP port (default 61613) to trusted clients only via firewall rules or network segmentation, though this is not a substitute for patching.

Patch guidance

Apply the vendor patches immediately: upgrade to ActiveMQ 5.19.8 or 6.2.7 (or any later stable release of either branch). Consult the Apache ActiveMQ release notes and security advisory for version-specific upgrade procedures. Test patches in a non-production environment before rolling out to production brokers to confirm compatibility with dependent applications. Plan upgrades during a maintenance window to minimize service disruption. For containerized deployments, rebuild images with the patched ActiveMQ version and redeploy containers.

Detection guidance

Monitor ActiveMQ broker logs for OutOfMemoryError exceptions or heap exhaustion warnings, which indicate successful exploitation attempts. Enable STOMP protocol logging at DEBUG level to capture malformed frames with unbounded headers. Network-level detection can identify multiple short-lived STOMP connections followed by broker restart (characteristic of denial-of-service probing). Monitor heap usage trending on broker JVM; sharp, unsustained increases warrant investigation. Intrusion detection signatures should flag STOMP connections transmitting unusually large single frames or headers without proper termination markers. Post-incident, review broker restart timestamps and access logs to correlate outage windows with suspicious external connections.

Why prioritize this

Despite lacking current KEV designation, this vulnerability merits immediate prioritization due to the combination of unauthenticated remote access, trivial exploitability, and guaranteed availability impact. The attack surface is network-wide if STOMP is exposed. Patched versions are readily available from the vendor. Organizations should prioritize this ahead of vulnerabilities with higher CVSS scores but lower ease of exploitation.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects a high-impact availability attack with a networked, unauthenticated attack vector and low complexity. The score appropriately excludes confidentiality and integrity impact since the vulnerability is purely a denial-of-service mechanism. The severity aligns with the threat landscape: an attacker can reliably disable a critical infrastructure component with minimal effort. Business context elevates practical risk beyond the base CVSS—in environments where ActiveMQ unavailability cascades to dependent systems, the functional impact may exceed a 7.5 numeric score.

Frequently asked questions