CVE-2024-32114: Apache ActiveMQ Auth Bypass Vulnerability

CVE-2024-32114 Overview

CVE-2024-32114 is an insecure default configuration vulnerability in Apache ActiveMQ 6.x that exposes critical API endpoints without authentication. The default configuration fails to secure the API web context, leaving the Jolokia JMX REST API and the Message REST API accessible to unauthenticated users. This vulnerability allows attackers to interact with the message broker, produce or consume messages, and purge or delete destinations without any credentials.

Critical Impact

Unauthenticated attackers can fully interact with Apache ActiveMQ broker through exposed REST APIs, potentially leading to data manipulation, message interception, and complete compromise of messaging infrastructure.

Affected Products

• Apache ActiveMQ 6.x (prior to version 6.1.2)
• Apache ActiveMQ deployments using default conf/jetty.xml configuration
• Systems exposing the Jolokia JMX REST API and Message REST API endpoints

Discovery Timeline

• 2024-05-02 - CVE CVE-2024-32114 published to NVD
• 2025-02-11 - Last updated in NVD database

Technical Details for CVE-2024-32114

Vulnerability Analysis

This vulnerability stems from a critical oversight in Apache ActiveMQ 6.x's default security posture. The default conf/jetty.xml configuration file ships without authentication constraints on the API web context, which hosts two critical interfaces: the Jolokia JMX REST API and the Message REST API.

The Jolokia JMX REST API provides a REST interface to Java Management Extensions (JMX), allowing external clients to monitor and manage the ActiveMQ broker. The Message REST API enables message production, consumption, and queue management operations. Without authentication requirements on these endpoints, any network-accessible attacker can leverage these APIs to compromise the messaging infrastructure.

This is classified under CWE-1188 (Insecure Default Initialization of Resource), as the vulnerability exists due to the product shipping with an insecure configuration rather than a code-level flaw.

Root Cause

The root cause is the absence of security constraints in the default Jetty configuration file (conf/jetty.xml). The configuration does not define authentication requirements for the API paths, meaning the securityConstraintMapping bean is either missing or not configured to protect the root path specification (/).

This design decision prioritized ease of initial setup over security, leaving organizations vulnerable if they deploy ActiveMQ without explicitly configuring authentication. The vulnerability demonstrates the importance of secure-by-default principles in enterprise software.

Attack Vector

The attack vector is network-based and requires no authentication or special privileges. An attacker with network access to an affected ActiveMQ instance can:

1. Access the Jolokia JMX REST API to query broker status, modify configurations, and execute management operations
2. Use the Message REST API to produce arbitrary messages to queues or topics
3. Consume messages from queues, potentially intercepting sensitive data
4. Purge or delete message destinations, causing denial of service or data loss

The attack requires some user interaction (as indicated by the CVSS vector), likely referring to scenarios where an attacker crafts malicious requests that a user or automated process triggers. However, direct exploitation by attackers with network access to the API endpoints remains viable.

Detection Methods for CVE-2024-32114

Indicators of Compromise

• Unexpected API requests to /api/jolokia or /api/message endpoints from external IP addresses
• Unauthorized queue or topic creation, modification, or deletion activities in broker logs
• Anomalous message production or consumption patterns indicating data exfiltration
• JMX operations executed without corresponding authenticated sessions

Detection Strategies

• Monitor HTTP access logs for requests to Jolokia and Message REST API endpoints without authentication headers
• Implement network-level monitoring for traffic to ActiveMQ API ports (default 8161) from untrusted sources
• Review broker audit logs for unexpected administrative operations or message queue manipulations
• Deploy web application firewalls (WAF) to detect and alert on unauthenticated API access attempts

Monitoring Recommendations

• Enable detailed access logging in Jetty configuration to capture all API requests with source IP and authentication status
• Configure SIEM alerts for failed authentication attempts followed by successful unauthenticated access patterns
• Implement network segmentation monitoring to detect unauthorized access to ActiveMQ management interfaces
• Establish baseline metrics for normal API usage and alert on deviations

How to Mitigate CVE-2024-32114

Immediate Actions Required

• Upgrade to Apache ActiveMQ 6.1.2 or later, which includes authentication by default
• If immediate upgrade is not possible, apply the configuration workaround to enforce authentication on the API context
• Review network access controls and restrict access to ActiveMQ management ports to trusted networks only
• Audit existing deployments for signs of unauthorized access or data manipulation

Patch Information

Apache has addressed this vulnerability in Apache ActiveMQ version 6.1.2, which updates the default configuration to require authentication for API access. Users should upgrade to this version or later to receive the security fix. The Apache ActiveMQ Security Advisory provides official guidance on this vulnerability.

Workarounds

• Modify the conf/jetty.xml configuration file to add authentication constraints as shown in the configuration example below
• Implement network-level access controls (firewalls, security groups) to restrict API endpoint access
• Deploy a reverse proxy with authentication in front of ActiveMQ API endpoints
• Consider disabling unused API interfaces if they are not required for operations

<!-- Add to conf/jetty.xml to enforce authentication -->
<bean id="securityConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">
  <property name="constraint" ref="securityConstraint" />
  <property name="pathSpec" value="/" />
</bean>