Apache ActiveMQ Classic, widely used as a messaging backbone in enterprise environments, carries a high-severity vulnerability tracked as CVE-2026-34197. What makes this particularly alarming is its roots. The underlying behavior enabling this vulnerability has existed for nearly 13 years, silently present across countless enterprise deployments.

The vulnerability arises from how the Jolokia JMX-HTTP bridge handles management operations, allowing authenticated users to trigger remote code execution within the broker process. Notably, the underlying behavior enabling this vulnerability has existed for almost 13 years, making it a long-standing risk in affected deployments.

Given ActiveMQ’s role in handling internal message flows and system integrations, exploitation can lead to exposure of sensitive data, credentials, and downstream services, making this a critical risk for affected deployments.

What Is CVE-2026-34197?

CVE-2026-34197 is an authenticated RCE vulnerability caused by unsafe exposure of management operations through the Jolokia API. The vulnerability arises when:

• The Jolokia endpoint (/api/jolokia/) allows execution of operations on ActiveMQ MBeans
• Specific operations such as addNetworkConnector accept user-controlled input
• That input can reference external configuration sources

By invoking these operations with a crafted request, an attacker can force the broker to fetch and process a remote Spring XML configuration file.

Risk Analysis

Severity: High
CVSS v3.1 Base Score: 8.8
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploit Availability: No
Exploit Complexity: Low

Access Requirement: Authenticated (default credentials commonly observed)

Impact: Arbitrary code execution on the broker JVM

The vulnerability is remotely exploitable and requires only valid access to the web console. In many environments, default credentials (admin:admin) are still in use, reducing the barrier to exploitation.

On versions 6.0.0 to 6.1.1, this risk increases further when combined with CVE-2024-32114, which exposes the Jolokia endpoint without authentication. In such cases, the vulnerability effectively becomes unauthenticated RCE.

Root Cause of CVE-2026-34197 in Apache ActiveMQ

CVE-2026-34197 results from the interaction of multiple design behaviors in Apache ActiveMQ .

The first factor is the Jolokia JMX-HTTP bridge, which exposes management operations over HTTP. The access policy permits execution (exec) of operations on ActiveMQ MBeans (org.apache.activemq:*), allowing authenticated users to invoke broker-level functions remotely.

The second factor lies in the addNetworkConnector operation, which accepts user-supplied URIs. These URIs can include the brokerConfig parameter, enabling the broker to load configuration from external locations, including remote URLs.

The third factor is how ActiveMQ processes these configurations. When a brokerConfig reference is provided, the broker uses Spring’s ResourceXmlApplicationContext to load the configuration. During this process, all defined beans are instantiated immediately as part of initialization.

When combined, these behaviors create a direct execution path:

• A remote request invokes a management operation
• The operation accepts attacker-controlled input
• The broker loads a remote XML configuration
• The configuration is processed and executed during initialization

Because execution occurs during the configuration loading phase, any embedded logic in the XML is executed before validation, or safety checks can take effect. This enables arbitrary code execution within the ActiveMQ broker process.

How CVE-2026-34197 is Exploited and its Impact

Exploitation of CVE-2026-34197 begins when an attacker accesses the ActiveMQ web console and interacts with the Jolokia API. In typical scenarios, authenticated access is sufficient, often achievable through default or weak credentials.

The attacker sends a crafted request to the /api/jolokia/ endpoint, invoking a management operation such as addNetworkConnector. This request includes a specially constructed URI containing a brokerConfig parameter that points to an attacker-controlled Spring XML configuration file.

When the broker processes this request, it attempts to establish a network connector using the supplied URI. As part of this process, it fetches the remote XML file and loads it using the application context. During initialization, all defined components within the XML are instantiated, leading to execution of attacker-controlled logic inside the ActiveMQ Java process. This execution inherits the privileges of the running service.

At this stage, the attacker gains code execution on the broker. This allows execution of system-level commands, modification of broker behavior, and deployment of persistent access mechanisms.

Control over the broker also exposes the messaging layer. Attackers can intercept, modify, or inject messages across queues, directly impacting application workflows and data integrity. Since ActiveMQ often connects to backend systems, configuration files and integrations may reveal credentials for databases, directory services, or APIs.

Once access is established, the broker can be used as a pivot point within the network. Depending on its connectivity, attackers can move laterally to other systems and services, extending the scope of compromise beyond the initial host.

Because ActiveMQ is typically embedded within internal infrastructure, exploitation does not remain isolated. It creates a direct path into connected systems and data flows, increasing the overall impact of the vulnerability.

CVE-2026-34197 Affected Versions

The following Apache ActiveMQ versions are affected by CVE-2026-34197:

Users are recommended to upgrade to version 5.19.4 or 6.2.3 to remediate this vulnerability. ActiveMQ Artemis is not affected.

Threat Hunting & Detection Guidance

Detecting exploitation of CVE-2026-34197 requires visibility across application, broker, and network layers. The attack leverages legitimate management operations, so indicators often appear as normal activity unless correlated carefully.

At the application layer, security teams should monitor requests to the /api/jolokia/ endpoint. Requests invoking operations such as addNetworkConnector, especially those containing parameters like brokerConfig or references to external XML resources, should be treated as suspicious. Repeated or abnormal use of these operations is a strong signal.

At the broker level, ActiveMQ logs provide key indicators. Look for network connector activity involving vm:// URIs combined with brokerConfig=xbean:http. Connection attempts to external configuration URLs, particularly those that repeat, are not typical in normal operations and should be investigated.

System-level behavior also provides visibility. The ActiveMQ Java process should not normally initiate unexpected child processes. Any such activity, along with outbound HTTP requests to unfamiliar hosts, may indicate exploitation.

Network telemetry adds another layer of detection. Outbound connections from the broker to unknown or untrusted systems, especially immediately following Jolokia API activity, should be treated as potential indicators of compromise.

Important: Log entries may include warnings after execution has already occurred. These messages do not indicate failed exploitation.  Detection should focus on identifying abnormal request patterns, broker activity, outbound communication, and error logs as core indicators of potential threats.

CVE: 2026-34197 Mitigation and Remediation

Organizations using affected Apache ActiveMQ versions should upgrade to fixed releases, specifically 5.19.4 or later and 6.2.3 or later, as these versions address the underlying problem.

Where immediate patching is not feasible, access to the Jolokia API should be restricted. If not required, the endpoint should be disabled. If it must remain enabled, access should be limited to non-exec operations to prevent invocation of management functions such as addNetworkConnector.

Access to the ActiveMQ web console should be controlled using strong authentication and network restrictions. Default credentials should be removed, and management interfaces should not be exposed beyond trusted environments.

Network controls should also be enforced to prevent broker systems from making outbound connections to untrusted hosts, reducing the risk of remote configuration loading.

For environments running versions 6.0.0–6.1.1, CVE-2024-32114 should also be patched, as it can expose the Jolokia API without authentication.

AppTrana WAAP Coverage

AppTrana WAAP has extended coverage for CVE-2026-34197 through dedicated detection rules targeting the specific request patterns associated with this vulnerability. Requests invoking sensitive Jolokia operations such as addNetworkConnector, particularly those containing brokerConfig parameters or references to external XML resources, are flagged and blocked before they reach the broker.

This coverage is in place as a proactive control, ensuring that if exploitation attempts emerge, they are intercepted at the perimeter without requiring changes to the underlying ActiveMQ deployment.

Screenshots showing malicious requests targeting the /api/jolokia/ endpoint associated with CVE-2026-34197, detected and blocked by AppTrana WAAP.

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.

The post CVE-2026-34197: Apache ActiveMQ Jolokia RCE Vulnerability appeared first on Indusface.

*** This is a Security Bloggers Network syndicated blog from Indusface authored by Deepak Kumar Choudhary. Read the original post at: https://www.indusface.com/blog/cve-2026-34197-apache-activemq-jolokia-vulnerability/