Apache ActiveMQ Security Guide: Lock Down Brokers, Jolokia and OpenWire

Apache ActiveMQ brokers are often deployed with authentication switched off, a web console still on admin/admin and the OpenWire port reachable from far more of the network than needs it. That matters because CVE-2023-46604, an unauthenticated OpenWire deserialisation flaw, is in the CISA Known Exploited Vulnerabilities (KEV) catalogue and marked as used in ransomware campaigns, and CVE-2026-34197, an authenticated code execution flaw through the Jolokia management API, joined it in April 2026. This guide covers ActiveMQ Classic: how clients, administrators and other brokers authenticate, how destination authorisation works, which credentials live in the broker's configuration, what to log, and a hardening baseline. It is for platform engineers, middleware administrators and security engineers. For the streaming side of messaging, see the Kafka Security Guide; ActiveMQ Artemis is a separate code base with its own security documentation and is not covered in detail here.

Key takeaways

• Upgrade brokers and clients together. The CVE-2023-46604 advisory tells users to upgrade "both brokers and clients", because the flaw is in the Java OpenWire marshaller that both sides use.
• The management plane is the bigger target now. Most 2026 ActiveMQ advisories concern Jolokia, the REST API and the web console, and CVE-2024-32114 left the 6.x API context unauthenticated by default before 6.1.2.
• Authentication is opt in. The broker does nothing until you configure simpleAuthenticationPlugin or jaasAuthenticationPlugin, and the web console's basic authentication is controlled by the authenticate property in conf/jetty.xml.
• Every application and bridge is a non-human identity. Producers, consumers, network connectors and bundled components each hold a username and password; give each its own account and destination rights.
• Restrict ObjectMessage deserialisation. Since 5.12.2 and 5.13.0 trusted packages must be listed explicitly; never set SERIALIZABLE_PACKAGES to * or setTrustAllPackages(true) in production.

How identity and access work in ActiveMQ

ActiveMQ Classic has three planes, each with its own authentication setting. Hardening only the messaging plane, and leaving the console and Jolokia open, is a common gap.

Messaging authentication

• simpleAuthenticationPlugin: users are defined inline as <authenticationUser username= password= groups=>. Simple, but the passwords sit in activemq.xml.
• jaasAuthenticationPlugin: names a JAAS entry in login.config, found through the java.security.auth.login.config system property or the classpath. Use it for LDAP (LDAPLoginModule, with a cached LDAP module from 5.6) or client certificates.
• Anonymous access: off unless anonymousAccessAllowed="true" is set. If you enable it, anonymous clients get the user and group anonymous, so authorisation entries must deny that group anything sensitive.
• Reload behaviour: from 5.12 JAAS property files load only at startup unless reload=true is set, so removing a user needs a reload or restart to take effect.
• LDAP cautions: the project's advisory list includes CVE-2021-26117 (LDAP authentication not verifying passwords against servers with anonymous bind) and CVE-2014-3612 (empty passwords accepted by LDAPLoginModule). Disable anonymous bind on the directory and stay on a current release. See the LDAP Security Deep Dive Guide.

Destination authorisation

Inside authorizationPlugin, an authorizationMap holds authorizationEntry elements for a queue or topic (wildcards such as ORDERS.> allowed). read allows browsing and consuming, write allows sending, and admin allows lazy creation of destinations. Two details catch teams out:

• Advisory topics: every user needs admin on ActiveMQ.Advisory destinations to create them, but normal users should not read or write all advisories. Open only ActiveMQ.Advisory.TempQueue and ActiveMQ.Advisory.TempTopic to everyone, and ActiveMQ.Advisory.Consumer.> to bridge users.
• Temporary destinations: without a tempDestinationAuthorizationEntry, all users get read, write and admin on temporary destinations. Several 2026 advisories (temporary destination ownership takeover, authorisation bypass via temporary composite destinations) show this area is still active.

Where the payload itself decides who may consume, a custom MessageAuthorizationPolicy with isAllowedToConsume(...) can be packaged into the broker's lib folder and configured as <messageAuthorizationPolicy>.

Admin roles and privileged access

Whoever reaches the web console or Jolokia with valid credentials can manage the broker, and since CVE-2026-34197 we know that can extend to running code: the default Jolokia policy allowed exec operations on broker MBeans such as addNetworkConnector, and a crafted discovery URI made the broker load a remote Spring XML context. Treat console access as privileged access to the host.

• Turn on console authentication: set authenticate to true in conf/jetty.xml (available since 5.4.0), replace admin/admin in jetty-realm.properties, and give each administrator a named account.
• Cover the whole Jetty context: the CVE-2024-32114 mitigation adds a ConstraintMapping with pathSpec / so the API context is covered too. Check that Jolokia and the REST API demand credentials after every upgrade.
• Separate viewers from operators: CVE-2026-49157 and CVE-2026-49877 describe low privilege web users keeping Jolokia broker management or console admin access by default. Upgrade, then test that a read-only role really is read-only.
• Bind and encrypt: the console listens on localhost in the documented default; keep it there or on a management network, and enable the secure connector in jetty.xml (the example uses port 8162 with a keystore) and remove the plain connector.
• Host and JMX access: remote JMX has had its own flaws (CVE-2020-11998, CVE-2020-13920). If you do not use remote JMX, leave it off; if you do, require authentication and TLS and restrict it to a management network. Host administrators can read every credential file, so manage them through your Privileged Access Management Guide process.

Integrations, API tokens and service accounts

An ActiveMQ estate holds more machine credentials than human ones. Each one belongs in your inventory with an owner.

For stronger client identity, use the SSL transport with transport.needClientAuth=true on the broker so each client presents a certificate, and map certificates to users through JAAS. Client hostname verification has been on by default since 5.15.6; do not turn it off with verifyHostName=false. Broker side hostname checking (transport.verifyHostName=true) is off by default and applies only to two-way TLS. The mTLS Guide covers the certificate lifecycle, and the Service Account Security Guide covers ownership and rotation.

Known exploited vulnerabilities and patching

Not in KEV but worth tracking: CVE-2024-32114 (API context unauthenticated by default, 6.x before 6.1.2) and CVE-2022-41678 (authenticated deserialisation via Jolokia). The project also lists CVE-2026-40466, a possible bypass of the CVE-2026-34197 fix, which is a reminder to take the latest release rather than the first fixed one.

1. Inventory: list every broker and every client library version, including JARs bundled inside applications and the activemq-all artefact. Software composition analysis or an SBOM finds client copies that a broker inventory misses.
2. Prioritise exposure: any broker whose OpenWire port is reachable from untrusted networks, or whose console is reachable outside a management network, goes first.
3. Test in a staging pair: upgrade a broker and a representative client, check authentication, authorisation, network connectors and ObjectMessage handling, and keep the previous binaries and conf directory for rollback.
4. Roll out: brokers in a failover pair one at a time, then client libraries through normal application releases.
5. Hunt: on any broker that was exposed and unpatched, check for unexpected child processes, new files and outbound connections before trusting it. See the Emergency Out-of-Band Patching Playbook.

Logging and detection

ActiveMQ logs through its logging configuration in conf; authentication failures and connection events show up there, but exploitation is clearest at the host. Forward both to the SIEM.

Metrics:

• Percentage of brokers and client libraries on a release that fixes all KEV entries.
• Number of brokers with OpenWire or the console reachable from untrusted networks (target: zero).
• Percentage of applications with their own broker account rather than a shared one.
• Number of authorisation entries granting admin on > to non-administrators (target: zero).
• Days to rotate broker credentials after a staff or supplier change.

Hardening baseline

1. Network: place brokers on an internal segment; allow 61616 (or your TLS port) only from application subnets and the console port only from a management network. Remove transport connectors for protocols you do not use.
2. Transport security: use ssl:// transports, set transport.enabledCipherSuites to a modern list, and require client certificates where applications can support them.
3. Authentication: enable jaasAuthenticationPlugin (LDAP or certificates) or at least simpleAuthenticationPlugin; leave anonymousAccessAllowed off.
4. Authorisation: one authorizationEntry per destination family, least privilege per application, explicit advisory and tempDestinationAuthorizationEntry rules.
5. Management plane: console authentication on, admin/admin gone, the whole Jetty context constrained, HTTPS only, and Jolokia limited or removed if no tool uses it.
6. Deserialisation: set org.apache.activemq.SERIALIZABLE_PACKAGES in ACTIVEMQ_OPTS to the packages you need and use setTrustedPackages() on clients; prefer text or bytes messages over ObjectMessage altogether. See the Secure Deserialisation Guide.
7. Credentials: change credentials.properties, use encrypted passwords or secrets injection, and restrict file permissions on conf to the broker service account.
8. Host: run the broker as a dedicated non-root account, block outbound internet access except what you need, and install EDR.

Choosing an approach: a small team with a single broker can get most of the benefit from simple authentication, per-application accounts, a closed console and fast upgrades. A large estate with networks of brokers should use JAAS with LDAP or certificates so accounts are managed centrally, and treat broker configuration as code reviewed in change control. If you are choosing a new message bus rather than hardening an existing one, compare the controls in the RabbitMQ Security Guide and the Kafka guide.

Common misconfigurations

• No broker authentication: the shipped configuration does not require credentials for messaging, so any host that can reach 61616 can send and consume.
• Patching the broker, not the clients: CVE-2023-46604 affects Java OpenWire clients too, and old client JARs live on in applications for years.
• Console exposed with default credentials: admin/admin on a reachable 8161 hands over broker management, and through Jolokia, potentially the host.
• Trusting all packages: SERIALIZABLE_PACKAGES=* or setTrustAllPackages(true), added to make an integration work in test, reopens Java deserialisation risk.
• One shared "system" account: every application using the bundled system credentials means no attribution and no least privilege.
• Bridge accounts with full rights: network connector users given admin on everything because advisory permissions were hard to get right.

Framework mapping

Practitioner checklist

• Inventory brokers and Java client libraries and upgrade both past every KEV fix.
• Enable broker authentication and keep anonymous access off.
• Write per-application authorisation entries, including advisory and temporary destination rules.
• Turn on console authentication, replace admin/admin, constrain the full Jetty context and serve it over HTTPS.
• Restrict or remove Jolokia and remote JMX; restrict console access to a management network.
• Change credentials.properties defaults and give each application and bridge its own account.
• Set trusted packages for ObjectMessage on broker and clients, never *.
• Use TLS transports with client certificates where possible and keep hostname verification on.
• Alert on the broker process spawning shells or fetching remote content.

Standards and references

• Apache ActiveMQ: Classic Security
• Apache ActiveMQ: Classic Security Advisories
• Apache ActiveMQ: CVE-2023-46604 Announcement
• Apache ActiveMQ: CVE-2026-34197 Announcement
• Apache ActiveMQ: Web Console
• Apache ActiveMQ: ObjectMessage
• Apache ActiveMQ: SSL Transport Reference
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Kafka Security Guide · RabbitMQ Security Guide · Insecure Deserialisation Guide · Ransomware Prevention Guide · Service Account Security Guide