--- title: "The Jolokia Problem: Eight CVEs, One Door in Apache ActiveMQ®" date: 2026-11-02 author: "Amit Agarwal" featured_image: "https://www.meshiq.com/wp-content/uploads/blog-activemq-jolokia-10302026.jpg" categories: - name: "Apache ActiveMQ®" url: "/sort-by/active-mq.md" - name: "Messaging" url: "/sort-by/messaging.md" - name: "Middleware" url: "/sort-by/middleware.md" - name: "Middleware Optimization" url: "/sort-by/middleware-optimization.md" - name: "Monitoring" url: "/sort-by/monitoring.md" - name: "MQ" url: "/sort-by/mq.md" --- # The Jolokia Problem: Eight CVEs, One Door in Apache ActiveMQ® This post is part of our [Apache ActiveMQ® CVE guide](https://www.meshiq.com/blog/apache-activemq-cve-guide/). It looks at the eight Jolokia CVEs as one problem rather than eight: what Jolokia exposes, why each patch missed the next attack, whether you need Jolokia at all, and how to lock down the whole surface rather than the latest hole. ## What Jolokia is, and why Apache ActiveMQ® ships it Jolokia is a bridge that turns JMX, Java’s management interface, into a JSON API over HTTP. Apache ActiveMQ® Classic has bundled it since version 5.8, when Apache added a [REST management API](https://activemq.apache.org/components/classic/documentation/rest) at /api/jolokia/. It lets monitoring tools and scripts read broker metrics and run management operations without a JMX client. In a stock Apache ActiveMQ® Classic installation, three files decide how it behaves: **File****What it controls**webapps/api/WEB-INF/web.xmlRuns the Jolokia agent servlet at /api/jolokia/\* and points it at a policy file through the policyLocation settingconf/jolokia-access.xmlThe Jolokia policy: which commands, MBeans, operations, HTTP methods, and client hosts are allowedconf/jetty.xmlThe web server: which address and port the console listens on (127.0.0.1:8161 by default since 5.16.0), and which URL paths need a login and which roleThe Apache ActiveMQ® start script passes the policy’s location to the broker, so conf/jolokia-access.xml is the file that counts. The 5.x line ships Jolokia 1.x and the 6.x line Jolokia 2.x. The power is the problem. Jolokia doesn’t only expose the broker’s own MBeans. Unless a policy says otherwise, it exposes every MBean in the Java process: the JVM’s diagnostics, its logging configuration, and its flight recorder. Each of those is a management feature. Over HTTP, with the wrong person holding the session, each can become a way to run code. ## Eight CVEs, one door These are the Apache ActiveMQ® Classic advisories whose Apache titles or descriptions route through Jolokia, oldest first: **CVE****Published****What it allowed****Login needed****Fixed in**[CVE-2022-41678](https://nvd.nist.gov/vuln/detail/cve-2022-41678)Nov 2023Reach JVM MBeans by reflection and write a web shellYes5.16.6, 5.17.4, 5.18.0, 6.0.0[CVE-2024-32114](https://nvd.nist.gov/vuln/detail/cve-2024-32114)May 2024Use Jolokia and the message REST API with no login at allNo6.1.2[CVE-2026-34197](https://nvd.nist.gov/vuln/detail/cve-2026-34197)Apr 2026Add a network connector that loads a remote Spring XML config, running codeYes (none on 6.0.0 to 6.1.1)5.19.4, 6.2.3[CVE-2026-40466](https://nvd.nist.gov/vuln/detail/cve-2026-40466)Apr 2026Bypass the 34197 fix through an HTTP discovery connectorYes5.19.6, 6.2.5[CVE-2026-41044](https://nvd.nist.gov/vuln/detail/cve-2026-41044)Apr 2026Trigger a crafted broker name through the DestinationView MBean to load remote Spring XMLYes5.19.6, 6.2.5[CVE-2026-45505](https://nvd.nist.gov/vuln/detail/cve-2026-45505)Jun 2026Bypass the 34197 fix with discovery wrappers such as static:vm://Yes5.19.7, 6.2.6[CVE-2026-42588](https://nvd.nist.gov/vuln/detail/cve-2026-42588)Jun 2026Load remote Spring XML through a masterslave: discovery URIYes5.19.7, 6.2.6[CVE-2026-49157](https://nvd.nist.gov/vuln/detail/cve-2026-49157)Jun 2026Non-admin web users could run admin operations such as addQueue and removeQueueYes, any web user5.19.7, 6.2.6All eight lead to code execution or control of the broker. Only CVE-2026-34197 is confirmed as exploited in the wild, and it was exploited within about a week of disclosure. Every one of them needs Jolokia to be reachable. Current status and scores for each are in the Apache ActiveMQ® CVE guide. ## Three eras of the same Jolokia mistake ### 2023: reflection reaches the JVM (CVE-2022-41678) The first Jolokia CVE didn’t touch the broker’s code at all. An authenticated user could call MBeans that belong to the Java runtime and its libraries. Apache’s description names the JDK Flight Recorder MBean on Java 11 and later, whose recording features could be made to write a file, such as a JSP web shell, into the web console’s directory. A [2025 peer-reviewed paper](https://www.mdpi.com/2073-431X/14/9/355) by researchers including Matei Bădănoiu, one of the CVE’s credited finders, documents a second route: Log4j2’s configuration MBeans, which give file-read, file-write, and server-side request primitives with no deserialization gadget needed. Apache’s fix ([AMQ-9201](https://issues.apache.org/jira/browse/AMQ-9201)) changed the default jolokia-access.xml. Before it, the policy denied only two JDK diagnostic MBeans. After it, the policy limited commands to read-only ones (read, list, version, search), denied the Log4j2 and Flight Recorder MBeans, and explicitly allowed all attributes and operations on the broker’s own MBeans. That last line matters. Jolokia’s [security documentation](https://jolokia.org/reference/html/manual/security.html) says an <allow> entry overrides the <commands> section. So the 2023 policy blocked the JVM’s dangerous MBeans but left every Apache ActiveMQ® broker operation callable, including addNetworkConnector. That is the operation CVE-2026-34197 used three years later. ### 2024: the door was left unlocked (CVE-2024-32114) In Apache ActiveMQ® 5.18.3, jetty.xml required a login for the console root, for /api/\* and for the console’s page types. In 6.0.0, the protected path list shrank to \*.jsp, and /api/\* dropped out of it. Jolokia and the message REST API were open to anyone who could reach port 8161. Apache fixed it in 6.1.2 by protecting everything under / ([AMQ-9477](https://issues.apache.org/jira/browse/AMQ-9477)), and its advisory gave a jetty.xml change for anyone who couldn’t upgrade. Apache scored it 8.5 and NIST 8.8, both High. On its own, it exposed management and messaging. Combined with CVE-2026-34197 two years later, it turned an authenticated code execution flaw into an unauthenticated one on 6.0.0 to 6.1.1. The lesson: the security of Jolokia doesn’t live only in Jolokia’s policy. It also lives in a web server file that most teams never read after installation. ### 2026: the broker’s own operations become the weapon CVE-2026-34197, found by Horizon3.ai and added to CISA’s KEV catalog on 16 April 2026, didn’t need the JVM’s MBeans. It called addNetworkConnector on the broker’s own MBean with a crafted discovery URI. The URI started an in-process broker over the VM transport, whose brokerConfig setting fetched a Spring XML file from the attacker’s server, and Spring ran code from it before the broker validated anything. Apache’s first fix blocked the VM transport in that operation. Four more advisories followed, each reaching the same result through a different URI form or MBean. Then CVE-2026-49157 showed that any authenticated web user, not just admins, could call broker management operations through Jolokia by default. We covered the exploitation timeline, the 6,400 vulnerable IP addresses Shadowserver counted, and how to check for compromise in our CISA KEV alert on CVE-2026-34197. Read the full alert → Apache’s response in 5.19.7 and 6.2.6 was finally structural. The shipped jolokia-access.xml now accepts only POST requests and explicitly denies a long list of broker operations, including addConnector, addNetworkConnector, stop, addQueue, removeQueue and purge, plus the MLet MBean, which can load remote classes. The shipped jetty.xml also gained a mapping that restricts /api/jolokia/\* to the admin role. ## ****Not sure what your Jolokia policy actually allows?**** meshIQ’s Apache ActiveMQ® consultants, led by Apache contributors, review your jolokia-access.xml, jetty.xml, and network exposure against every Jolokia CVE, and hand you a documented hardening plan. [************Book a Jolokia Security Review************](https://www.meshiq.com/solutions/apache-activemq/consulting/) ## Why the Jolokia patches keep missing Looking at the eight CVEs together, four patterns explain why each fix left room for the next: 1. **Deny lists chase attacks.** Every policy change before 2026 blocked a named MBean or operation. A deny list stops the route someone already found. The next researcher picks a route that isn’t on it. An allow list of the few operations you actually use stops routes nobody has found yet. 2. **Policy is configuration, and configuration doesn’t upgrade itself.** The fixes for CVE-2022-41678, CVE-2024-32114, and CVE-2026-49157 all live in files under conf/. Upgrade tooling and configuration management usually preserve those files. A broker running 5.19.11 binaries with a jolokia-access.xml from 2022 has the 2022 policy. 3. **Authentication was treated as authorization.** Until CVE-2026-49157, being logged in to the web console was enough to call broker management operations through Jolokia. Add a default admin:admin login, and “requires authentication” protects very little. 4. **Legitimate features chain into exploits.** Network connectors, discovery URIs, the VM transport, and Spring configuration all work as designed. Horizon3.ai made this point about CVE-2026-34197: the danger is the chain. Code fixes can break one chain. Only removing reach breaks all of them. ## Do you need Jolokia at all? Most teams never decided to run Jolokia. It came with the console. Start by deciding what it’s for: **How you use the broker****What you need from Jolokia****Recommendation**No HTTP-based monitoring; you use JMX directly or a separate agentNothingRemove the /api contextDashboards or exporters that read metrics over HTTPRead-only accessRead-only policy, monitoring hosts only, POST onlyScripts or tools that change the broker over HTTP (create queues, purge, pause)Specific operationsAllow only those operations, admin role only, management network onlyHawtio or another external consoleBroad read and execTreat as privileged admin access: admin role, management network, current releaseNot sureUnknownTurn on access logging for /api/jolokia/ for two weeks and see who calls itIf your monitoring goes through a dedicated tool rather than raw Jolokia calls, the decision gets easier. We’ll cover how to set that up in our upcoming [Monitoring & Alerting guide](https://www.meshiq.com/blog/activemq-monitoring-alerting-setup/). ## Hardening the whole Jolokia surface ### Layer 1: run a release that closes all eight As of October 2026, Apache ActiveMQ® 5.19.11 and 6.3.2 and later fix every Jolokia CVE above, and every other 2026 Apache ActiveMQ® Classic advisory. The latest are 5.19.12, 6.3.3 and 6.4.0 (27 October 2026). The 6.2.x, 6.1.x and 6.0.x lines are end-of-life. 5.19.7 and 6.2.6 are the minimum for the Jolokia family. Then reconcile your configuration. Compare your conf/jolokia-access.xml and conf/jetty.xml line by line with the files shipped in the new release, and carry your customizations onto the new files, not the other way round. We’ll cover how to fold this into your patch process in our upcoming [Upgrade & Patching Strategy guide](https://www.meshiq.com/blog/activemq-upgrade-patching-strategy/). ### Layer 2: restrict who can call it In conf/jetty.xml, Jolokia should require the admin role, not just any login. Since 5.19.7 and 6.2.6, the shipped jetty.xml includes a mapping of this shape, which applies the existing admin constraint to the Jolokia path: <!– conf/jetty.xml (5.19.x): Jolokia for admins only –> <**bean** id=”jolokiaSecurityConstraintMapping” class=”org.eclipse.jetty.security.ConstraintMapping”> <**property** name=”constraint” ref=”adminSecurityConstraint” /> <**property** name=”pathSpec” value=”/api/jolokia/\*” /> </**bean**>The mapping only takes effect once it’s added to the security handler’s list of constraint mappings. The 6.x line runs a newer Jetty with different role names (admins, users), so copy the pattern from the jetty.xml shipped with your 6.x release rather than this snippet. Then make the login itself mean something. Replace admin:admin in conf/jetty-realm.properties, give each person their own account, and don’t put service accounts in the admin role. ### Layer 3: restrict what can be called Start from the jolokia-access.xml shipped with your release, then tighten it. For read-only monitoring, a policy of this shape allows reads from known hosts and nothing else: <!– conf/jolokia-access.xml: read-only monitoring –> <**restrict**> <**http**> <**method**>post</**method**> </**http**> <**remote**> <**host**>127.0.0.1</**host**> <**host**>10.20.30.0/24</**host**> <!– your monitoring subnet –> </**remote**> <**commands**> <**command**>read</**command**> <**command**>list</**command**> <**command**>version</**command**> <**command**>search</**command**> </**commands**> <**cors**> <**strict-checking**/> </**cors**> </**restrict**>Three details decide whether a policy like this holds: - **No broad** **<allow>** **entries.** An <allow> overrides <commands>. An <allow> for org.apache.activemq:\* with all operations re-opens everything the command list closed. That is exactly what the 2023 policy did. - **Keep the deny entries from the shipped file if you keep any exec access.** They block the JVM, logging, and class-loading MBeans used in past attacks. - **Check the policy path.** Apache ActiveMQ® points Jolokia at the file with a file: URL, and Jolokia’s documentation says a missing file at a non-classpath location denies all access. A policy looked up on the classpath that fails to load does the opposite: it grants everything, with only a log warning. Don’t change how the path is set without testing. Test your monitoring after any change. Anything that performs operations through Jolokia will stop working, which is the point, but you want to find out before production does. ### Layer 4: restrict where it can be reached from Keep the console bound to 127.0.0.1 or a management interface in jetty.xml, firewall port 8161 to management subnets, and use the <remote> hosts list as a second check. Jolokia should never be reachable from user networks, let alone the internet. If a monitoring tool needs it remotely, put that tool on the management network rather than opening the port. ### Layer 5: remove it, or watch it If nothing needs Jolokia, remove it. It runs inside the /api web application, defined as a WebAppContext with the context path /api in conf/jetty.xml. Removing or commenting out that context removes both Jolokia and the deprecated message REST API. Apache doesn’t document this step, so test it on a non-production broker first and confirm the /admin console still works. If you keep it, watch it. Log requests to /api/jolokia/, alert on any request that uses exec or write, and alert on network connectors added at runtime. A broker that suddenly gains a network connector, or fetches a URL, is a broker to look at today. ## ****See your brokers without opening Jolokia to the network**** meshIQ Console gives your team monitoring, alerting and JMX management for Apache ActiveMQ® brokers, so the Jolokia HTTP bridge never has to be reachable from user networks. [************See meshIQ Console************](https://www.meshiq.com/request-a-demo/) ## Jolokia audit checklist Run this against every Apache ActiveMQ® Classic broker in your estate: - The broker runs 5.19.11 or 6.3.2 or later (or at minimum 5.19.7 or 6.2.6). - conf/jolokia-access.xml matches, or is stricter than, the file shipped with that release. - The policy has no <allow> entry granting all operations on org.apache.activemq:\* unless you need it. - The policy accepts POST only and lists the client hosts allowed to call it. - conf/jetty.xml requires a login for everything under /, and the admin role for /api/jolokia/\*. - admin:admin and other default credentials are gone from conf/jetty-realm.properties. - The console listens on 127.0.0.1 or a management interface, and port 8161 is firewalled. - Someone has decided whether the /api context is needed, and removed it if not. - Requests to /api/jolokia/ are logged and exec calls raise an alert. - Every broker that ran a vulnerable version with a reachable console has been checked for compromise. Our Apache ActiveMQ® Security Hardening Guide covers the layers around Jolokia, including TLS, JAAS and LDAP authentication and network isolation, with a 17-item checklist. [Read the full hardening guide →](https://www.meshiq.com/blog/activemq-security-hardening-guide/) ## **Frequently asked questions** **Q1. **What is Jolokia in Apache ActiveMQ®?**** Jolokia is a JMX-to-HTTP bridge that Apache ActiveMQ® Classic has bundled since version 5.8. It exposes the broker’s management operations as a JSON API at /api/jolokia/ on the web console port, 8161 by default, so tools can monitor and manage the broker over HTTP. **Q2. Which Apache ActiveMQ® CVEs involve Jolokia?** Eight since 2023, by Apache’s own advisory titles: CVE-2022-41678, CVE-2024-32114, CVE-2026-34197, CVE-2026-40466, CVE-2026-41044, CVE-2026-45505, CVE-2026-42588 and CVE-2026-49157. CVE-2026-34197 is in CISA’s Known Exploited Vulnerabilities catalog. **Q3. **Can I disable Jolokia in Apache ActiveMQ®?**** Yes, if nothing depends on it. Jolokia runs in the /api web application defined in conf/jetty.xml, so removing that context removes the endpoint. Apache does not document this step, so test it first and confirm your monitoring tools do not call /api/jolokia/. **Q4. **Is upgrading enough to secure Jolokia?**** Not always. The fixes that matter most ship as configuration files: conf/jolokia-access.xml and conf/jetty.xml. An upgrade that keeps your old copies of those files keeps the old, weaker policy. Compare your files against the ones shipped with the new release. **Q5. **Does Jolokia affect Apache Artemis™?**** The eight CVEs covered here are Apache ActiveMQ® Classic advisories. Apache Artemis™ also ships Jolokia behind its Hawtio-based console, with its own access controls and advisories, so apply the same principles: restrict who and where can reach it, and allow only the operations you need. **Q6. ****Close the Jolokia door, not just this year’s hole**?**** Eight CVEs in three years say the next Jolokia advisory is a question of when. Patching each one as it lands keeps you a step behind. Deciding what Jolokia should do in your estate, and enforcing it in policy, role and network, keeps you ahead. meshIQ’s Apache ActiveMQ® consulting team, led by Apache contributors, reviews your brokers, designs the policy, and documents it so it survives the next upgrade.