Description
Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ.
During unmarshalling of OpenWire commands the size value of buffers was not properly validated which could lead to excessive memory allocation and be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on the availability of the ActiveMQ broker when not using mutual TLS connections.
This issue affects Apache ActiveMQ: from 6.0.0 before 6.1.6, from 5.18.0 before 5.18.7, from 5.17.0 before 5.17.7, before 5.16.8. ActiveMQ 5.19.0 is not affected.
Users are recommended to upgrade to version 6.1.6+, 5.19.0+, 5.18.7+, 5.17.7, or 5.16.8 or which fixes the issue.
Existing users may implement mutual TLS to mitigate the risk on affected brokers.
Product(s):
- Apache Software Foundation ActiveMQ 5.16.0
- Apache Software Foundation ActiveMQ 5.16.1
- Apache Software Foundation ActiveMQ 5.16.2
- APACHE > activemq 5.*.*
- Apache Software Foundation ActiveMQ 5.16.6
- Apache Software Foundation ActiveMQ 5.16.7
- Apache Software Foundation ActiveMQ 5.17.0
- Apache Software Foundation ActiveMQ 5.17.6
- Apache Software Foundation ActiveMQ 5.18.3
Question to Ask Vendors:
- Have you updated all instances of Apache ActiveMQ to the patched versions (6.1.6 or later, 5.19.0 or later, 5.18.7 or later, 5.17.7 or later, 5.16.8 or later) to mitigate the risk of CVE-2025-27533?
- Have you implemented mutual TLS (mTLS) on your Apache ActiveMQ to prevent unauthorized clients from establishing connections to the broker and potentially exploiting CVE-2025-27533?
- Are you monitoring resource usage and broker performance for sudden spikes in memory usage or degradation, which could indicate exploitation attempts of CVE-2025-27533?
- Have you restricted network access to ActiveMQ broker ports, especially OpenWire (typically TCP port 61616), to only trusted IP ranges or internal systems to prevent potential exploitation of CVE-2025-27533?
Recommended Actions:
- Develop an Incident Response Plan: Prepare your IR team to respond to a broker-level DoS scenario by including procedures for isolating affected brokers, restarting services, and rerouting messaging workloads if necessary.
- Implement Mutual TLS: For affected brokers that cannot yet be upgraded, enforce mutual TLS (mTLS) to mitigate unauthenticated remote access. This ensures that only trusted clients can initiate connections to the broker.
- Inspect Logs and Network Traffic: Review ActiveMQ logs and network traffic for anomalies or malformed OpenWire command activity. Look for signs of unexpected connections or memory exhaustion patterns.
- Monitor Resource Usage: Set up automated monitoring and alerting for sudden spikes in memory usage or broker performance degradation, which may signal exploitation attempts.
- Restrict Network Access: Limit access to ActiveMQ broker ports—especially OpenWire (typically TCP port 61616)—to only trusted IP ranges or internal systems. Do not expose these services directly to the internet.
- Test Application Compatibility: After upgrading, validate that internal applications depending on ActiveMQ still function as expected, especially if custom clients or non-default protocols are in use.
- Upgrade Immediately: Update Apache ActiveMQ to one of the patched versions: 6.1.6 or later, 5.19.0 or later, 5.18.7 or later, 5.17.7 or later, 5.16.8 or later.
- Use Web Application Firewalls (WAF) or Proxies: If possible, front ActiveMQ brokers with reverse proxies or WAFs that can enforce additional traffic validation and rate-limiting for OpenWire and other protocols.