CVE-2026-39304: Apache ActiveMQ DoS Vulnerability

CVE-2026-39304 Overview

CVE-2026-39304 is a Denial of Service (DoS) vulnerability affecting Apache ActiveMQ components that arises from improper handling of TLSv1.3 handshake KeyUpdates in NIO SSL transports. When a malicious client rapidly triggers TLS key updates, the broker can exhaust all available memory in the SSL engine, leading to a complete denial of service condition.

This vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption), highlighting the fundamental issue of resource exhaustion through uncontrolled memory allocation during TLS handshake operations.

Critical Impact

A remote, unauthenticated attacker can cause complete service unavailability by exhausting broker memory through rapid TLSv1.3 KeyUpdate requests, potentially disrupting enterprise messaging infrastructure.

Affected Products

• Apache ActiveMQ Client: versions before 5.19.4, and from 6.0.0 before 6.2.4
• Apache ActiveMQ Broker: versions before 5.19.4, and from 6.0.0 before 6.2.4
• Apache ActiveMQ: versions before 5.19.4, and from 6.0.0 before 6.2.4

Discovery Timeline

• April 10, 2026 - CVE-2026-39304 published to NVD
• April 13, 2026 - Last updated in NVD database

Technical Details for CVE-2026-39304

Vulnerability Analysis

The vulnerability exists within the NIO (Non-blocking I/O) SSL transport layer of Apache ActiveMQ. The TLSv1.3 protocol introduced a new mechanism for key updates during an active session, allowing either party to request fresh cryptographic keys without performing a full handshake renegotiation. However, ActiveMQ's implementation fails to properly rate-limit or manage resources when processing these KeyUpdate requests.

When a client initiates rapid successive KeyUpdate messages, the broker's SSL engine allocates memory for each update operation. Without proper bounds checking or resource management, this leads to unbounded memory growth. The broker continues allocating memory until system resources are exhausted, resulting in an Out of Memory (OOM) condition and service failure.

Notably, earlier TLS versions (such as TLSv1.2) exhibit different behavior when exploited similarly. While these versions are technically broken in their handling of renegotiation requests, they cause connections to hang rather than triggering memory exhaustion. This is because older TLS versions require a full handshake renegotiation, which is a more resource-constrained operation.

Root Cause

The root cause is uncontrolled resource consumption (CWE-400) in the NIO SSL transport implementation. The code path handling TLSv1.3 KeyUpdate messages lacks proper safeguards for:

1. Rate limiting of incoming KeyUpdate requests
2. Maximum memory allocation bounds for SSL engine operations
3. Detection and mitigation of abnormal KeyUpdate frequency patterns

The SSL engine continues processing KeyUpdate requests without imposing limits on how frequently they can occur or how much memory can be consumed, allowing attackers to trigger memory exhaustion through sustained rapid requests.

Attack Vector

The attack can be executed remotely over the network without requiring any authentication or user interaction. An attacker establishes a TLSv1.3 connection to a vulnerable ActiveMQ broker using NIO SSL transport, then rapidly sends KeyUpdate messages. Each KeyUpdate forces the broker to allocate additional memory for cryptographic state management. By sustaining this attack, the attacker can exhaust the broker's available heap memory, causing the JVM to throw OutOfMemoryError exceptions and crash the service.

The attack is particularly effective because:

• No authentication is required to establish a TLS connection
• KeyUpdate messages are part of the normal TLS protocol flow
• The memory consumption accumulates faster than garbage collection can reclaim resources

For detailed technical information, refer to the Apache ActiveMQ Security Advisory.

Detection Methods for CVE-2026-39304

Indicators of Compromise

• Unusual memory consumption patterns on ActiveMQ broker processes, particularly in the SSL/TLS engine components
• High frequency of TLS KeyUpdate messages from individual client connections
• JVM OutOfMemoryError exceptions in broker logs
• Broker service crashes or restarts coinciding with suspicious TLS connection activity
• Abnormally long-lived TLS connections with minimal data throughput but high handshake activity

Detection Strategies

• Monitor JVM heap usage metrics for ActiveMQ broker instances, alerting on rapid memory growth
• Implement network-level monitoring to detect unusual TLS handshake patterns and KeyUpdate frequency
• Configure JVM garbage collection logging to identify memory pressure events
• Deploy application performance monitoring to correlate TLS connection events with memory consumption
• Review broker logs for patterns indicating SSL engine memory allocation failures

Monitoring Recommendations

• Set up threshold alerts for ActiveMQ broker memory usage exceeding normal operational baselines
• Implement connection monitoring to track TLS session characteristics and KeyUpdate frequencies
• Enable detailed SSL/TLS logging to capture handshake events for forensic analysis
• Configure JVM heap dump on OOM to capture state for post-incident analysis
• Monitor network traffic for patterns consistent with TLS-based DoS attacks

How to Mitigate CVE-2026-39304

Immediate Actions Required

• Upgrade Apache ActiveMQ to version 6.2.4 or 5.19.5 which contain the fix for this vulnerability
• If immediate upgrade is not possible, consider temporarily disabling TLSv1.3 and using TLSv1.2 (note: connections may hang but OOM will be prevented)
• Implement network-level rate limiting on TLS connections to ActiveMQ brokers
• Configure JVM memory limits and OOM killer settings to prevent complete system failure
• Review and restrict network access to ActiveMQ brokers to trusted clients only

Patch Information

Apache has released patched versions that address this vulnerability:

• Version 6.2.4 - Recommended upgrade for users on the 6.x branch
• Version 5.19.5 - Recommended upgrade for users on the 5.x branch

The patches implement proper resource management for TLSv1.3 KeyUpdate handling and also address the connection hanging issue present in earlier TLS versions. Refer to the Apache ActiveMQ Security Advisory and the OpenWall OSS-Security Mailing List Post for additional details.

Workarounds

• Restrict TLS protocol versions by configuring the broker to disable TLSv1.3 support temporarily (this prevents OOM but connections may hang under attack)
• Implement network-level connection rate limiting and source IP filtering for SSL/TLS endpoints
• Configure firewall rules to limit the number of concurrent connections from individual source addresses
• Use a reverse proxy or load balancer with TLS termination and DoS protection capabilities in front of ActiveMQ brokers
• Implement JVM-level memory constraints with appropriate heap settings to limit the blast radius of memory exhaustion attacks

# Example: Disable TLSv1.3 in ActiveMQ configuration (temporary workaround)
# In activemq.xml, modify the SSL context configuration:
# <sslContext>
#   <sslContext keyStore="broker.ks" keyStorePassword="password"
#     protocols="TLSv1.2"/>
# </sslContext>

# Alternatively, set JVM property to disable TLSv1.3
export ACTIVEMQ_OPTS="$ACTIVEMQ_OPTS -Djdk.tls.client.protocols=TLSv1.2 -Djdk.tls.server.protocols=TLSv1.2"