---
title: "ActiveMQ Upgrade & Patching Strategy: The Expert Guide"
date: 2026-07-21
author: "TheFrameGuy"
featured_image: "https://www.meshiq.com/wp-content/uploads/blog_activeMQ-upgrade_072126.jpg"
categories:
  - name: "Apache ActiveMQ®"
    url: "/sort-by/active-mq.md"
  - name: "Devops"
    url: "/sort-by/devops.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"
  - name: "Observability"
    url: "/sort-by/observability.md"
  - name: "SaaS"
    url: "/sort-by/saas.md"
tags:
  - name: "devops"
    url: "/sort-by/tag/devops.md"
  - name: "middleware"
    url: "/sort-by/tag/middleware.md"
  - name: "monitoring"
    url: "/sort-by/tag/monitoring.md"
  - name: "Observability"
    url: "/sort-by/tag/observability.md"
---

# ActiveMQ Upgrade & Patching Strategy: The Expert Guide

Within days, threat actors were exploiting it to deploy the HelloKitty ransomware. Two years later, CVE-2026-34197, another RCE via OpenWire deserialization, was added to the CISA Known Exploited Vulnerabilities catalog, with federal agencies required to patch within three weeks.

The message is not subtle: unpatched ActiveMQ brokers on enterprise networks are high-value targets with well-documented exploitation paths. An upgrade and patching strategy for ActiveMQ is not an operational nicety, it is a security obligation.

This guide covers the complete ActiveMQ upgrade and patching strategy: CVE response urgency tiers, pre-upgrade checklists, step-by-step upgrade procedures for Apache ActiveMQ® and Apache Artemis™, client-broker backward compatibility rules, the version lifecycle and supported release windows, and rollback procedures.

## **CVE Response: Patch Urgency Tiers**

Not all vulnerabilities require emergency response. The patch urgency framework maps CVE characteristics to response timelines, ensuring that critical RCE vulnerabilities receive emergency treatment while low-severity advisories are handled in normal release cycles.

**Tier****Criteria****Response Timeline****Example****Emergency**CISA KEV-listed, CVSS ≥ 9.0 with public exploit, active exploitation confirmed24-72 hours – emergency changeCVE-2023-46604 (CVSS 10.0), CVE-2026-34197 (CISA KEV)**Expedited**CVSS 7.0-8.9 with RCE or auth bypass, no confirmed exploitation7-14 days – expedited maintenance windowCVE-2022-41678 (Jolokia RCE, CVSS 8.8)**Scheduled**CVSS 4.0-6.9, no RCE, limited attack surface30-60 days – next scheduled maintenance windowDoS, XSS, and limited scope auth issues**Normal cycle**CVSS < 4.0, requires local access or authenticated contextInclude in the next planned release cycleMinor information disclosure



**Monitoring sources for new CVEs and advisories**:

- activemq.apache.org/components/classic/security – Apache ActiveMQ® security advisories
- activemq.apache.org/components/artemis/documentation/latest/versions.html – Apache Artemis™ version notes with security flags
- Apache Security Announcements mailing list: announce@apache.org (very low volume, high signal)
- CISA Known Exploited Vulnerabilities Catalog: cisa.gov/known-exploited-vulnerabilities-catalog
- Your organization’s vulnerability scanner (Qualys, Tenable, Prisma) should detect ActiveMQ CVEs automatically if the broker is in scope

Emergency response when no maintenance window is available: for CVSS ≥ 9.0 vulnerabilities without an available upgrade path, apply mitigating controls from our [**Security Hardening Guide**](https://www.meshiq.com/blog/activemq-security-hardening-guide/) post, network-level ACLs restricting broker port 61616 access to authorized clients only, disabling the OpenWire transport if the vulnerability is in OpenWire, and clients can use AMQP. These are not remediation, they are interim risk reduction until patching is completed.

## **Version Lifecycle: Are You Running a Supported Version?**

Apache ActiveMQ does not publish a formal support lifecycle document. The community practice is:

- **Apache ActiveMQ®**: the last two minor releases of the current series receive security patches. As of 2026, Classic 5.18.x, 5.19.x, and 6.x are the active series. Classic 5.16.x is at end-of-life (the project announced this explicitly: “This is the last planned Classic 5.16.x release”). Classic 5.15.x is end-of-life.
- **Apache Artemis™**: Only the latest minor version is actively maintained. The community does not backport fixes to older minor versions.

**Current Apache ActiveMQ® major series requirements**:

- Classic 5.x (5.18.x, 5.19.x): Java 11+ required
- Classic 6.x (6.1.x, 6.2.x): Java 11+ required (Java 17 recommended)

**Critical JDK requirement change**: Classic 6.x introduced a dependency on Jakarta EE (javax → jakarta namespace migration). Applications using the javax.jms API must migrate to jakarta.jms when moving to Classic 6.x clients. The broker itself is backward compatible, a Classic 6.x broker accepts connections from Classic 5.x clients. The client-side namespace change is what breaks applications.

**Minimum supported version recommendation**: always run the latest patch release of your current minor series (e.g., the latest 5.18.x release if you are on 5.18, not just any 5.18 release). Patch releases within a minor series are always backward compatible and safe to apply.

\# Check current broker version from Classic log at startup  
grep “Apache ActiveMQ” /opt/activemq/data/activemq.log | grep “started”  
\# Expected: INFO | Apache ActiveMQ 5.18.3 (localhost, …) started

\# Check current Artemis version  
grep “AMQ221001” /opt/artemis/log/artemis.log | tail -1  
\# Expected: AMQ221001: Apache ActiveMQ Artemis Message Broker version 2.31.0 …

## **Pre-Upgrade Checklist**

Complete every item before initiating an upgrade. Skipping any step is a rollback risk.

PRE-UPGRADE CHECKLIST

**1. BACKUP: Full backup of current installation and data**  
 – activemq.xml / broker.xml  
 – bin/env (Classic) / etc/artemis.profile (Artemis)  
 – conf/log4j2.properties / etc/log4j2.properties  
 – conf/login.config, credentials.properties  
 – Custom JARs in lib/  
 – KahaDB data directory / Artemis journal (if stopped-backup is possible)

 See our [**Backup & DR guide**](https://www.meshiq.com/blog/activemq-backup-disaster-recovery/) for the complete backup procedure.

**2. VERSION REVIEW: Read release notes for all versions between**  
 current and target, not just the target version.  
 Check the versions page for breaking changes in any intermediate release.

**3. BREAKING CHANGE SCAN: Identify changes that affect your deployment**  
 – JDK version requirements increased?  
 – Configuration element names changed?  
 – Default behavior changes (e.g., verifyHost in Artemis 2.29+)?  
 – API changes affecting client libraries?

**4. CLIENT COMPATIBILITY: Verify your client library versions**  
 – Confirm OpenWire protocol version compatibility  
 – If upgrading Classic 5.x → 6.x: check javax.jms vs jakarta.jms  
 – Test client connections against the new broker version in staging

**5. STAGING TEST: Apply the upgrade in a staging environment**  
 that mirrors production load and configuration  
 – Run the application workload for at least 1 hour post-upgrade  
 – Verify message delivery, persistence, and failover behavior

**6. ROLLBACK PLAN: Document the exact steps to revert**  
 – Identify the rollback trigger (specific error pattern, metric threshold)  
 – Time estimate for rollback execution  
 – Who has the authority to call a rollback during the upgrade window

**7. MAINTENANCE WINDOW: Schedule with appropriate lead time**  
 – Notify application teams of broker maintenance  
 – Confirm monitoring is in place for the upgrade period  
 – Verify backup/restore procedure with a practice run

## **Upgrading Apache ActiveMQ®: Step-by-Step Procedure**

Apache ActiveMQ® does not have a formal upgrade helper tool like Apache Artemis™. The procedure is manual, but straightforward when followed correctly.

The golden rule for Apache ActiveMQ® upgrades: never upgrade in-place. Always extract the new version to a separate directory and copy your configuration files across. In-place overwrite risks silently overwriting customized configuration files with defaults.

\# ============================================================  
\# ActiveMQ Classic Upgrade Procedure  
\# Example: 5.18.2 → 5.18.3 (patch upgrade, same minor series)  
\# ============================================================  
  
**\# Step 1: Back up the running installation** TIMESTAMP=$(date +%Y%m%d-%H%M%S)  
BACKUP\_DIR=”/opt/activemq-backup-${TIMESTAMP}”  
cp -a /opt/activemq “${BACKUP\_DIR}”  
echo “Backup saved to ${BACKUP\_DIR}”  
  
**\# Step 2: Download and verify the new release** \# Get SHA512 checksum from downloads.apache.org  
wget https://archive.apache.org/dist/activemq/5.18.3/apache-activemq-5.18.3-bin.tar.gz  
wget https://archive.apache.org/dist/activemq/5.18.3/apache-activemq-5.18.3-bin.tar.gz.sha512sha512sum -c apache-activemq-5.18.3-bin.tar.gz.sha512  
  
**\# Step 3: Extract to a parallel directory (NOT in-place)** tar -xzf apache-activemq-5.18.3-bin.tar.gz -C /opt/  
\# Creates: /opt/apache-activemq-5.18.3/  
  
**\# Step 4: Copy YOUR configuration files from old installation to new** \# Configuration files to migrate:  
NEW\_HOME=/opt/apache-activemq-5.18.3  
  
\# Core broker configuration  
cp /opt/activemq/conf/activemq.xml ${NEW\_HOME}/conf/activemq.xmlcp /opt/activemq/conf/log4j2.properties ${NEW\_HOME}/conf/log4j2.propertiescp /opt/activemq/conf/login.config ${NEW\_HOME}/conf/login.configcp /opt/activemq/conf/credentials.properties ${NEW\_HOME}/conf/credentials.properties 2>/dev/null || true  
  
\# JVM options — CRITICAL: most commonly forgotten step  
cp /opt/activemq/bin/env ${NEW\_HOME}/bin/env  
\# bin/env contains ACTIVEMQ\_OPTS with your heap size, GC flags, JMX settings  
\# Without this copy, the new broker starts with 512MB heap defaults  
  
\# Custom JARs (Prometheus exporter, plugins, etc.)  
\# DO NOT blindly copy lib/ — check for version conflicts with new release  
ls /opt/activemq/lib/optional/ | diff – <(ls ${NEW\_HOME}/lib/optional/)  
\# Copy specific custom JARs that were not part of the standard distribution  
  
cp /opt/activemq/lib/optional/activemq-web-console\*.war ${NEW\_HOME}/lib/optional/ 2>/dev/null || true  
  
**\# Step 5: Stop the running broker gracefully** /opt/activemq/bin/activemq stop  
sleep 10  
\# Verify the process has stopped  
pgrep -f “activemq” && echo “WARNING: ActiveMQ still running” || echo “Broker stopped”  
  
**\# Step 6: Create a symlink for clean version management (optional but recommended)** ln -sfn /opt/apache-activemq-5.18.3 /opt/activemq  
\# Now /opt/activemq always points to the current version  
  
**\# Step 7: Start the broker from the new installation** /opt/activemq/bin/activemq start  
  
**\# Step 8: Verify the version in the startup log** sleep 10  
grep “Apache ActiveMQ” /opt/activemq/data/activemq.log | grep “started”  
\# Expected: INFO | Apache ActiveMQ 5.18.3 (localhost, …) started  
  
**\# Step 9: Monitor for errors in the first 15 minutes** tail -f /opt/activemq/data/activemq.log | grep -E “ERROR|WARN|Exception”

**Log4j2 migration note**: If upgrading from Classic 5.16.x or earlier to 5.17.0+, the logging framework changed from log4j1/reload4j to log4j2. Your existing log4j.properties (log4j1 format) will not work with the new version. You must migrate to the log4j2.properties format. The new distribution ships a working log4j2 default, treat it as your starting point and apply your customizations to it, rather than copying the old file.

## **Upgrading Apache Artemis™: The ARTEMIS\_HOME Model**

The Apache Artemis™ upgrade design is its most operationally elegant feature. Because the broker “home” (JAR files, scripts) is separated from the broker “instance” (data, configuration), upgrading the broker binaries does not touch your data or configuration files.

\# ============================================================  
\# ActiveMQ Artemis Upgrade Procedure  
\# Example: 2.30.0 → 2.31.0 (minor upgrade)  
\# ============================================================  
  
**\# Step 1: Download and extract new Artemis home alongside the existing one** wget https://archive.apache.org/dist/activemq/activemq-artemis/2.31.0/apache-artemis-2.31.0-bin.tar.gz  
tar -xzf apache-artemis-2.31.0-bin.tar.gz -C /opt/  
\# Creates: /opt/apache-artemis-2.31.0/  
\# Existing /opt/apache-artemis-2.30.0/ remains untouched  
  
**\# Step 2: Use the artemis upgrade CLI to update the instance scripts** \# This updates bin/artemis, etc/artemis.profile, etc/artemis-utility.profile  
\# to point ARTEMIS\_HOME at the new version  
cd /opt/apache-artemis-2.31.0/bin/  
./artemis upgrade /opt/artemis-instance  
\# The CLI:  
\# – Updates ARTEMIS\_HOME in artemis.profile to /opt/apache-artemis-2.31.0  
\# – Updates bin/artemis script to new version  
\# – Creates log4j2.properties if upgrading from a pre-2.27.0 instance  
\# – Removes old logging.properties if present  
\# Your broker.xml, data/, and log/ directories are NOT touched  
  
**\# Step 3: Check for version-specific migration steps** \# Always read the versions page before upgrading between minor versions# Key changes to look for:  
\# – Artemis 2.29+: verifyHost default changed from false to true for Core SSL  
\# – Artemis 2.27+: log4j2.properties replaces logging.properties  
\# Review: activemq.apache.org/components/artemis/documentation/latest/versions.html  
  
**\# Step 4: For Artemis 2.29+ upgrade — check SSL configuration** \# If your clients use SSL Core protocol, verify hostname verification is aligne  
dgrep -r “verifyHost” /opt/artemis-instance/etc/  
\# If verifyHost=false is already explicitly set, behavior is unchanged  
\# If not set, it now defaults to true — test SSL connectivity in staging first  
  
**\# Step 5: Stop the broker gracefully** /opt/artemis-instance/bin/artemis-service stop  
\# Or if running as a service:  
systemctl stop artemis  
  
**\# Step 6: Start the broker from the instance directory** /opt/artemis-instance/bin/artemis-service start  
  
**\# Step 7: Verify the version in startup log** grep “AMQ221001” /opt/artemis-instance/log/artemis.log | tail -1  
\# Expected: AMQ221001: Apache ActiveMQ Artemis Message Broker version 2.31.0 …  
  
**\# Step 8: Monitor for errors** tail -f /opt/artemis-instance/log/artemis.log | grep -E “ERROR|AMQ2\[0-9\]{5}\[^0\]”

**Rollback procedure (Apache Artemis™)**: because the instance data is untouched, rollback is as simple as reverting the ARTEMIS\_HOME pointer:

\# Artemis rollback: revert ARTEMIS\_HOME to previous version  
sed -i ‘s|/opt/apache-artemis-2.31.0|/opt/apache-artemis-2.30.0|’ \\  
 /opt/artemis-instance/etc/artemis.profile

\# Restart  
systemctl restart artemis

\# Verify rollback  
grep “AMQ221001” /opt/artemis-instance/log/artemis.log | tail -1

This is why Artemis’s home/instance separation is such an operational advantage; the rollback time is measured in seconds, not minutes.

## Responding to an ActiveMQ CVE and Need Help Patching Safely?

CVE patches require urgency without sacrificing safety. meshIQ’s team has guided enterprise organizations through emergency ActiveMQ patching operations, including rolling upgrades on HA clusters, coordinated client upgrades, and post-patch validation under production load.

[Get Emergency Upgrade Support](https://www.meshiq.com/solutions/apache-activemq/enterprise-support/)







## **Client-Broker Backward Compatibility**

ActiveMQ’s compatibility stance is strong: older clients connecting to newer brokers generally work without changes. The OpenWire protocol negotiates the highest mutually supported version at connection time, meaning a client using the 5.15.x library connecting to a 5.18.x broker will negotiate a compatible protocol version automatically.

### **Apache ActiveMQ® Compatibility Rules**

**Same minor series** (e.g., 5.18.1 client → 5.18.3 broker): fully compatible. Patch releases within a minor series never introduce wire-level protocol changes.

**Different minor series, same major** (e.g., 5.15.x client → 5.18.x broker): generally compatible. The broker is designed to maintain backward wire compatibility within the 5.x series. Validate in staging for minor version gaps > 2.

**5.x client → 6.x broker**: The broker is backward compatible at the wire protocol level, OpenWire clients still work. The critical change is on the client side: Classic 6.x introduced the Jakarta EE namespace (jakarta.jms instead of javax.jms). Applications using the javax.jms API must continue using 5.x client libraries when connecting to a 6.x broker, or must migrate their application code to jakarta.jms. The broker does not force client code changes.

### **Apache Artemis™ Compatibility Rules**

Apache Artemis™ is backward compatible at the protocol level across versions. The significant breaking change in Artemis 2.29+ is the SSL verifyHost default change:

Artemis 2.29+ breaking change: ARTEMIS-3367  
Default verifyHost on Core connectors changed from false to true.  
Core clients using SSL will now expect the broker’s CN or SAN to match  
the hostname in the client’s URL.

Impact:  
– Core JMS clients using SSL with certificate/hostname mismatch → connection failure  
– Core connections between cluster nodes → connection failure if SSL + hostname mismatch  
– OpenWire, AMQP, MQTT, STOMP clients → NOT affected (different protocol, different SSL layer)

Resolution options:  
1\. Update SSL certificates to include the hostname as CN or SAN (recommended)  
2\. Explicitly set verifyHost=false in client connector configuration (interim mitigation)  
3\. Add verifyHost=false to broker.xml cluster connectors for broker-to-broker connections

**JDK compatibility**: Apache Artemis™ upgrades that change the minimum JDK version (e.g., the 2.34+ upgrade to Java 17 due to Jetty 12 dependency) do not break client applications. The JDK version requirement is for the broker JVM, not the client JVM. Older client JDKs continue to work.

## **Upgrading Apache ActiveMQ® with HA: Rolling Procedure**

For Apache ActiveMQ® deployments using Master/Slave HA, a rolling upgrade achieves near-zero downtime:

Rolling Upgrade on Apache ActiveMQ® HA Pair:

Step 1: Identify the current SLAVE broker  
 → It will not be serving clients

Step 2: Upgrade the SLAVE broker first (it’s already not serving traffic)  
 → Apply the Classic upgrade procedure on the slave node  
 → Start the upgraded slave in standby mode  
 → Verify the upgraded slave is in the standby state:  
 grep “slave” /opt/activemq/data/activemq.log

Step 3: Force a failover to the newly upgraded slave  
 → Stop the MASTER broker  
 → The upgraded slave becomes MASTER  
 → Clients reconnect via failover transport (transparent, typically 2-5 seconds)  
 → Verify the upgraded broker is now MASTER:  
 grep “started” /opt/activemq/data/activemq.log

Step 4: Upgrade the original MASTER (now SLAVE)  
 → Apply the Classic upgrade procedure on what was the master  
 → Start the upgraded node as the new SLAVE  
 → Verify synchronization with the current MASTER

Step 5: Optionally fail back to the original MASTER  
 → Or leave the upgraded-first node as MASTER  
 → Both nodes are now running the new version

The client failover transport handles the brief connection interruption during master/slave switchover. We covered the failover transport configuration (failover:(broker1:61616,broker2:61616)?timeout=30000) in our [**High Availability Architecture Guide**](https://www.meshiq.com/blog/activemq-high-availability-architecture/).

For Apache Artemis™ live-backup replication, the same principle applies: upgrade the passive backup first, trigger failover, upgrade the original active, restore the original active as the new backup.

## **Upgrade on Kubernetes: StatefulSet Rolling Update**

For Kubernetes deployments using StatefulSets (covered in our [**ActiveMQ on Kubernetes**](https://www.meshiq.com/blog/activemq-kubernetes-deployment/) post), Kubernetes’s native RollingUpdate strategy handles broker upgrades:

\# StatefulSet with RollingUpdate strategy for controlled upgrades  
spec:  
 updateStrategy:  
 type: RollingUpdate  
 rollingUpdate:  
 partition: 0 # Update all pods; set to N to leave N pods on old version

**Upgrade procedure for Kubernetes**:

\# Update the image tag in the StatefulSet to the new broker version  
kubectl set image statefulset/activemq \\  
 activemq=apache/activemq-classic:5.18.3 \\  
 -n messaging  
  
\# Watch the rolling update progress  
kubectl rollout status statefulset/activemq -n messaging  
  
\# Verify the pod is running the new version  
kubectl exec activemq-0 -n messaging — \\  
 /opt/activemq/bin/activemq version

**Important**: StatefulSets with a PodDisruptionBudget of minAvailable: 1 will not replace the pod if it would drop below minimum availability. For a single-replica broker, the upgrade causes a brief restart, accept the downtime window or use HA to avoid it.

## **Post-Upgrade Validation**

After every upgrade, regardless of whether it is a security patch or a minor version update, run this validation sequence before closing the maintenance window:

**\# Post-Upgrade Validation Script**  
  
ACTIVEMQ\_LOG=”/opt/activemq/data/activemq.log” # Adjust for Artemis  
  
\# 1. Version confirmation  
echo “=== Version ===”  
grep -m 1 “Apache ActiveMQ.\*started” “${ACTIVEMQ\_LOG}”  
  
\# 2. All expected connectors started  
echo “=== Connectors ===”  
grep “Connector.\*started” “${ACTIVEMQ\_LOG}”  
\# Expected: one line per configured transport connector  
  
\# 3. No ERROR in first 5 minutes of operation  
echo “=== Errors (first 5 min after start) ===”  
STARTED\_AT=$(grep -m 1 “started” “${ACTIVEMQ\_LOG}” | cut -d’|’ -f1)  
\# Manual: check for ERROR lines after the “started” timestamp  
grep “ERROR” “${ACTIVEMQ\_LOG}” | tail -20  
  
\# 4. KahaDB recovery completed successfully (if applicable)  
echo “=== KahaDB Recovery ===”  
grep “Recovery replayed” “${ACTIVEMQ\_LOG}”  
  
\# 5. Client connectivity test  
echo “=== Connectivity Test ===”  
/opt/activemq/bin/activemq producer \\  
 –brokerUrl tcp://localhost:61616 \\  
 –user admin –password admin \\  
 –destination queue://upgrade.test \\  
 –messageCount 1 –sleep 100 && \\  
/opt/activemq/bin/activemq consumer \\  
 –brokerUrl tcp://localhost:61616 \\  
 –user admin –password admin \\  
 –destination queue://upgrade.test \\  
 –messageCount 1 && \\  
echo “SUCCESS: Message round-trip verified”  
  
\# 6. Web console accessible  
curl -s -o /dev/null -w “%{http\_code}” http://localhost:8161/admin/  
\# Expected: 401 (auth required = web console running) or 200 (if auth disabled)  
  
\# 7. JMX health metrics  
echo “=== Memory Percent Usage ===”  
\# Via JMX/CLI or monitoring: verify MemoryPercentUsage is within normal bounds  
\# A sudden jump indicates the new version has different default memoryUsage settings

We covered the complete log analysis and diagnostic patterns in our **[Log Analysis & Diagnostics](https://www.meshiq.com/blog/activemq-log-analysis-diagnostics/)** post. The post-upgrade window is when you want log monitoring at its most sensitive — run with the log-based alerts active and watch for any unexpected WARN or ERROR patterns during the first production traffic cycle.

## Post-Upgrade Monitoring to Confirm Healthy Broker State

meshIQ Console provides a real-time broker health view during and after upgrades, showing memory utilization, connection counts, queue depths, and error patterns across all brokers. The upgrade validation checklist becomes a live dashboard.

[See It in Action](https://www.meshiq.com/request-a-demo/)









## **Upgrade Cadence Recommendations**

**Scenario****Recommended Upgrade Cadence****Security patch within same minor**Apply within the patch urgency tier timeline, never skip**Minor version update (bug fixes)**Quarterly or with each 2-3 patch releases**Major version update (5.x → 6.x, Artemis minor)**Annually, with a dedicated test/staging cycle**Apache ActiveMQ® 5.15.x or 5.16.x (EOL)**Urgent – upgrade to 5.18.x or 6.x immediately; no more security patches**Apache Artemis™ is behind by more than 2 minor versions**Plan upgrade within 90 days

**EOL urgency**: running an EOL version means future CVEs receive no patch. CVE-2026-34197 was patched in 5.18.4, an operator running 5.16.x had no patch to apply and was permanently exposed.

## **An Upgrade Cadence Is a Security Posture**

The CVE history of Apache ActiveMQ® demonstrates that critical RCE vulnerabilities are not rare events, they recur. CVE-2023-46604 was exploited within days of disclosure. CVE-2026-34197 was added to CISA’s KEV catalog within weeks of discovery.

The operations teams that patched CVE-2023-46604 within 48 hours were not fortunate, they had a patch cadence, a tested upgrade procedure, and a rollback plan already in place. Building that infrastructure before the next CVE is the point of this guide.

**Get your ActiveMQ upgrade procedure reviewed and hardened by our team → [Get Upgrade Support](https://www.meshiq.com/solutions/apache-activemq/enterprise-support/)**

## **Frequently Asked Questions**

**Q: How do I upgrade ActiveMQ Apache ActiveMQ®?**

Extract the new version to a separate directory. Copy activemq.xml, bin/env (JVM options), log4j2.properties, and login.config from the old installation. Stop the old broker, start the new. Never in-place overwrite.

**Q: How do I upgrade Apache Artemis™?**

Extract the new Artemis home alongside the old. Run ./artemis upgrade PATH\_TO\_INSTANCE from the new home’s bin directory. Change ARTEMIS\_HOME in etc/artemis.profile. Rollback is reverting that one line.

**Q: Are ActiveMQ clients backward compatible with newer broker versions?**

Yes for same-major minor upgrades. The OpenWire protocol version is negotiated at connection time. Apache ActiveMQ® 6.x introduces jakarta namespace – 5.x clients connect fine at the wire level, but application code using javax.jms must stay on 5.x client libraries. Artemis 2.29+ SSL verifyHost change may break Core SSL clients with certificate/hostname mismatches.

**Q: How quickly do I need to patch ActiveMQ CVEs?**

CVSS ≥ 9.0 or CISA KEV-listed: 24–72 hours (emergency). CVSS 7.0–8.9: 7-14 days. CVSS 4.0–6.9: next scheduled maintenance window. Monitor the Apache security advisory page and CISA KEV catalog.

**Q: What is the supported version lifecycle for ActiveMQ?**

Apache ActiveMQ®: last two minor releases of the current series. 5.15.x and 5.16.x are EOL. Apache Artemis™: latest minor version only. Monitor endoflife.date/apache-activemq for community-tracked lifecycle dates.