// ActiveMQ Classic extended support
ActiveMQ 5.18 is end of life.
Attackers have noticed.
ActiveMQ Classic brokers are a favourite target: two ActiveMQ remote code execution flaws are on CISA's Known Exploited Vulnerabilities catalog. The 5.18 line no longer receives fixes, the 6.x line needs a javax to jakarta migration, and Amazon MQ offers no 6.x at all. OSSeva patches the brokers you have while you choose the path.
Trusted globally by enterprises
Why ActiveMQ Classic estates are stuck
There are two ways off ActiveMQ 5.x, and both are application projects rather than broker upgrades.
ActiveMQ 6.x means Jakarta Messaging
The 6.x line moves from the javax.jms API to jakarta.jms. Applications built on Spring 5 or other javax-based stacks have to move with it, which is usually the larger migration.
Artemis is a different broker
Moving from Classic to Artemis changes the storage engine, the configuration model and parts of the client behaviour. OpenWire clients keep working in many cases, but it is a re-platform, not an upgrade.
Amazon MQ stops at 5.19
Amazon MQ for ActiveMQ supports only 5.18 and 5.19 and offers no 6.x engine, so managed brokers have no in-service path to Jakarta Messaging.
The dates that matter
2023-11-02
CVE-2023-46604, an OpenWire remote code execution flaw in ActiveMQ Classic, is added to CISA's KEV catalog with known ransomware use.
2025-03
ActiveMQ 5.18.x marked inactive; 5.18.7 is the last release on the line.
2026-04-16
CVE-2026-34197, remote code execution through the Jolokia endpoint by an authenticated attacker, is added to CISA's KEV catalog. Fixed in 5.19.4 and 6.2.3, not on 5.18.
What OSSeva delivers
Patched ActiveMQ 5.x brokers
Backported fixes for the 5.x line you run, including broker, web console and Jolokia components, delivered as signed builds.
Exposure review
Which brokers expose OpenWire, the web console or Jolokia beyond where they should, and which compensating controls close the gap today.
Classic to 6.x or Artemis
A decision on the destination, then the javax to jakarta or Classic to Artemis migration, broker by broker.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Upgrade to 5.19 or 6.2 | Upstream fixes, including CVE-2026-34197 | 6.x needs the Jakarta migration; 5.19 is a stopgap on the same javax line. |
| Migrate to Artemis | The actively developed ActiveMQ broker | A re-platform with storage, configuration and client testing. |
| OSSeva extended support | Patched 5.x brokers now, migration help later | A subscription per broker estate. |
| Stay unpatched | Nothing | An internet-facing broker with KEV-listed flaws is among the most exploited middleware there is. |
CVE details from NVD and CISA's Known Exploited Vulnerabilities catalog; release status from activemq.apache.org; Amazon MQ versions from AWS documentation.
Frequently asked questions
Is ActiveMQ 5.18 still supported?
No. The Apache ActiveMQ project marks 5.18.x as inactive, and 5.18.7 was the last release. Fixes now ship on 5.19 and 6.x.
Is ActiveMQ 5.18 affected by CVE-2026-34197?
The flaw affects ActiveMQ Classic before 5.19.4 and 6.x before 6.2.3, and there is no 5.18 release that fixes it. Exploitation requires an authenticated attacker to reach the Jolokia endpoint. It has been on CISA's KEV catalog since 16 April 2026.
Should we move to ActiveMQ 6 or to Artemis?
If your applications already use jakarta.jms or can move with modest effort, 6.x keeps the Classic operating model. If you are re-platforming anyway, Artemis is the broker the project is investing in. We help you decide per estate.
Can you patch brokers on Amazon MQ?
No one can patch a managed broker except the provider. For Amazon MQ the options are 5.19 in place or a move to self-managed brokers, which we can support.
Patch the brokers attackers are scanning for.
Discovery call, broker inventory and exposure review, proposal within five working days.