Apache Artemis Vulnerabilities by Version: CVEs for ActiveMQ Artemis 1.x and 2.x

The short answer

Artemis has no maintenance branches. Every release since 2.32.0 in January 2024 has been a new minor version off a single branch, the download page offers only the newest one, and each advisory names that newest release as its fix. Today that is 2.57.0, released on 9 September 2026. The Artemis security page lists 20 CVEs, ten of them published in 2026, and 2.57.0 is the only release that fixes all ten. A broker on 2.44.0, the last release under the ActiveMQ Artemis name, is missing all ten. One on 2.31.2 or 2.32.0, where many estates pinned, is missing those ten, two from 2025 and a 2024 federation fix as well.

For the September 2026 batch in detail, including the session takeover flaw CVE-2026-57967, see Apache ActiveMQ Artemis CVE-2026-57967. This guide is the lookup table: find the release you run and see what it is missing.

Artemis releases and the CVEs they are missing

Because there are no maintained lines, the rows below are ranges of releases that share the same list of unfixed CVEs. Dates are from the Artemis past releases page. Each row includes every CVE in the rows above it, plus the ones named.

For release dates on the recent lines, see the ActiveMQ Artemis end-of-life chart. The project publishes no end-of-life or support policy, so every release other than the newest is effectively out of support the day its successor ships.

Notable Artemis CVEs by release range

CVSS is NVD's own score where NVD has scored the record. The September 2026 records carry only the CVSS 3.1 score CISA-ADP added, marked CISA-ADP, and CVE-2026-101292 carries only Red Hat's score as the CNA. The rating column is Apache's own. None of these CVEs is in CISA's Known Exploited Vulnerabilities catalogue.

The 2026 list splits into two groups. Six of the ten, CVE-2026-27446, CVE-2026-57967, CVE-2026-49364, CVE-2026-67593, CVE-2026-49362 and CVE-2026-49363, need no credentials at all, so users and roles in broker.xml do not stop them. What matters is who can reach the acceptors, especially the default acceptor on port 61616, which accepts Core connections out of the box. An acceptor URL with no protocols parameter accepts every protocol. The rest need an authenticated user, and most of them only matter where different applications share a broker under different permissions.

The rename also affects scanning. Releases up to 2.44.0 use the Maven group org.apache.activemq and releases from 2.50.0 use org.apache.artemis, and there were no releases numbered 2.45 to 2.49. A scanner that matches only one group ID will miss half of each affected range.

What each release range gets

Artemis 2.57.0

2.57.0 is the only release with every fix above. It needs Java 17 or later. When the next release ships, 2.57.0 will be in the position 2.56.0 is in now, so staying current means taking each new minor release.

Artemis 2.50 to 2.56

These are the first releases under the Apache Artemis name. All of them are missing the seven September 2026 fixes, and 2.50.0 and 2.51.0 are also missing the fix for CVE-2026-27446, the only CVE the project rates critical. Moving to 2.57.0 is a minor upgrade on the same Java baseline.

ActiveMQ Artemis 2.39 to 2.44

These run on Java 17 and carry every fix up to 2025, but none from 2026. CVE-2026-27446 reaches back to 2.11.0, and the September batch reaches back to 1.0.0. The upgrade to 2.57.0 crosses the rename, so check build files and scanners for the new group ID. Until the upgrade, the CVE-2026-27446 advisory lists three mitigations: remove Core from acceptors that untrusted clients reach, require two-way TLS, or deploy a Core interceptor that rejects downstream federation connect packets.

ActiveMQ Artemis 2.28 to 2.38

This is where many brokers stopped, because 2.39.0 moved the minimum Java version from 11 to 17. A broker on 2.31.2 or 2.32.0 is missing the ten 2026 fixes, the 2.40.0 fixes for CVE-2025-27391 and CVE-2025-27427, and the 2.34.0 fix for CVE-2026-101292. A broker on 2.28.0 is also missing the 2.29.0 fix for CVE-2023-50780, which lets an authenticated Jolokia user write files and reach code execution. Getting to 2.57.0 from here means a JDK upgrade first.

ActiveMQ Artemis 2.27 and older, and 1.x

Older 2.x releases add CVE-2022-35278 in the web console, CVE-2022-23913 before 2.19.1, and CVE-2021-26117 before 2.16.0, which matters to anyone using the LDAP login module. Releases before 2.4.0 also lack the fix for CVE-2017-12174, a memory exhaustion bug in UDP and JGroups discovery, which 1.5.6 also fixed. Artemis 1.x, the first generation built from the HornetQ code base, ended with 1.5.6.

What to do on each release range

• 2.57.0. Stay current, and make taking each new Artemis release part of routine patching, since no older release gets fixes.
• 2.50 to 2.56. Move to 2.57.0.
• 2.39 to 2.44. Move to 2.57.0 and update the Maven group ID. Until then, remove Core from acceptors untrusted clients can reach, or require client certificates.
• 2.38 and older. Upgrade the JDK to 17 and move to 2.57.0, or take patched builds from a supplier that backports fixes. Until then, restrict network access to every acceptor, disable UDP discovery where you do not need it, limit who can log in to the Jolokia console, and keep debug logging off the ConfigurationImpl logger.

Estates running both brokers can check ActiveMQ Classic in the same way with ActiveMQ Classic vulnerabilities by version, and the Classic to Artemis migration guide covers moving between them.

Where OSSeva fits

OSSeva ships CVE-patched, GPG-signed builds of Artemis 2.28.x to 2.32.x, the Java 11 releases many estates are pinned on, covering the AMQP 1.0, OpenWire, MQTT and STOMP protocols and delivered through Maven or Docker. OSSeva backports fixes of this class to the end-of-life release lines it patches. They are available now on the Patch, Assure and Operate tiers. Assure adds a live-live HA architecture review, an address and queue security audit and an ActiveMQ Classic to Artemis migration assessment, and Operate adds 24/7 broker monitoring with a 15-minute P1 response and a named senior Artemis engineer. See ActiveMQ Artemis support.