CVE-2026-49364, CVE-2026-27446 & 8 More: Apache ActiveMQ Artemis 2026 CVE Round-Up

In 2026 Apache Artemis published ten security advisories, as many as in the previous decade combined. The headliners are CVE-2026-49364, a pre-authentication cluster credential exposure (CWE-306) scored 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) by CISA's Authorized Data Publisher (ADP) enrichment, and CVE-2026-27446, an authorization bypass in Core downstream federation that NVD scores 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Six of the ten affect Apache ActiveMQ Artemis from 1.0.0, and a seventh from 1.3.0, meaning effectively every broker and client release in the project's history. The fixes for the largest batch landed only in Artemis 2.57.0, which requires Java 17, ships Jakarta-only artifacts, publishes under the new org.apache.artemis Maven groupId, and changes the Core handshake in a way that forces a cluster-wide lockstep upgrade. The org.apache.activemq line ends at 2.44.0, still vulnerable, so no OSS fix exists for any Spring Boot managed Artemis version, Boot 4.1 included. HeroDevs Never-Ending Support (NES) for Apache ActiveMQ Artemis v2.19.4 resolves six of the seven 2.57.0-batch fixes on the 2.19.x line as a drop-in, coordinate-compatible replacement (coverage status for CVE-2026-57822 is in the mitigation section), and NES 2.19.3 resolved CVE-2026-27446 in August 2026.

Affected and unsupported? See NES for Apache ActiveMQ Artemis.

Give me the TL;DR on the 2026 Artemis CVEs

If you can migrate to Artemis 2.57.0 or later under the new org.apache.artemis groupId, do it. That closes everything in this round-up. But understand what that migration costs before you schedule it: Java 17 minimum, Jakarta artifacts, a groupId change in every build file, a replaced management console, new handshake behavior, and a requirement to upgrade every broker in a secured cluster together.

If you are pinned to an older Artemis through Spring Boot, you cannot get there with a version bump. Boot 2.7 manages Artemis 2.19.1 on Java 8-era javax artifacts, and even current Boot 4.1 manages 2.53.0, which is vulnerable to the entire 2.57.0 batch. For the 2.19.x line, NES for Apache ActiveMQ Artemis v2.19.4 fixes the Critical and High entries in this round-up with a one-property change and no JDK, namespace, or coordinate migration.

The ten 2026 Artemis CVEs

Severity labels below are from the Apache Artemis security page. Where a HeroDevs vulnerability directory entry exists, the CVE links there; the three without entries link to cve.org.

Note the severity labels diverge between sources. The HeroDevs vulnerability directory rates CVE-2026-49364, CVE-2026-57967, and CVE-2026-67593 Critical, and CVE-2026-49362 and CVE-2026-49363 High, while Apache labels them Important and Moderate. Apache rates against its own criteria; the directory ratings track the scored impact.

The pattern: the broker does too much before authenticating

Group the Important and Critical entries by what they let an attacker do and one theme emerges.

Pre-authentication queue manipulation. CVE-2026-67593 let a client open an OpenWire connection and delete a named queue with a single RemoveSubscriptionInfo command before authenticating. CVE-2026-49362 let an unauthenticated client create durable queues through CREATE_QUEUE packets on the CORE session-creation channel. And CVE-2026-57967 let an unauthenticated connection reattach to, and take over, another client's authenticated CORE session.

Pre-authentication disclosure and credential exposure. CVE-2026-49363 handed the full cluster topology, members and connector configuration included, to any unauthenticated client that asked. CVE-2026-49364 is the highest-impact of the set even though two siblings score higher: a broker using discovery groups trusted every broadcast it received, so a network-adjacent attacker could advertise a fake node and receive the configured cluster administrative credentials during the connection handshake (CWE-306). The directory entry confirms artemis-core-client is affected alongside artemis-server, so this is not a broker-only problem.

Deserialization denial of service. CVE-2026-57822 (CWE-502) is the one Important entry that requires authentication: a client authorized with MANAGE permission can craft message-based management parameters whose deserialization pins the processing thread.

Federation authorization bypass. CVE-2026-27446, disclosed earlier in the year, let an unauthenticated attacker send a Core downstream federation request and make the broker open an outbound federation connection to a broker the attacker controls, enabling message injection and exfiltration.

Every one of these is the broker, or the client library, doing something meaningful before it has established who it is talking to. This is one bug class found systematically across the CORE and OpenWire handshake paths, not a scatter of unrelated issues. And the affected ranges start at 1.0.0: these flaws have existed for the life of the project.

Artemis CVE severity and CVSS scores

NVD analysis was slow to land for this batch. Where NVD's own analysts have scored, that score is noted; the remainder carry CVSS 3.1 vectors from CISA's ADP enrichment recorded in the NVD entries.

Every entry above except CVE-2026-75880 and CVE-2026-57822 carries PR:N: no credentials required. The two PR:L entries require an authenticated messaging client, and CVE-2026-57822 additionally requires MANAGE permission.

Exploitation status of the 2026 Artemis CVEs

None of the ten CVEs appear in the CISA Known Exploited Vulnerabilities catalog as of October 6, 2026, and we found no public proof-of-concept exploit for any of them as of October 6, 2026. The Apache announcements document mechanisms, not payloads.

That said, the attack preconditions for the worst entries are configuration states that are common in the field. CVE-2026-49364 requires server discovery to be enabled, which was the default behavior before 2.57.0, and pays out the configured cluster credentials. Deployments still running the default cluster-user / cluster-password pair, which Artemis only began rejecting in 2.54.0, turn that disclosure into immediate cluster compromise. Audit both conditions regardless of your patch status.

Why Artemis 2.57.0 is a fork in the road, not a patch

The 2.57.0 release that fixes the main batch is not a drop-in. Per the upstream versions documentation, the fix is a protocol change:

• The Core connect handshake now carries credentials at connection time, via ServerLocator.setConnectionCredentials(user, password) or createSessionFactory(user, password).
• Secured Core connections are limited to 4 KiB frames until authenticated, then raised to 128 KiB.
• Unauthenticated clients receive a placeholder topology instead of the real cluster view.
• In a secured cluster, every broker must be upgraded before versions are mixed. An old broker connecting to an upgraded one is treated as unauthenticated and gets only the placeholder topology, so cluster connections, bridges, replication, and backup registration can fail or stall. The documented workaround during transition is disabling coreConnectionSecurityEnabled, which reopens the exposure.
• Server discovery is disabled by default.
• LIKE selector filters cap % wildcards at five, and a broker will refuse to start if persisted durable subscriptions exceed the limit.

Stack the prerequisites on top: 2.57.0 requires Java 17 (since 2.39.0), ships Jakarta-only artifacts, and exists only under the org.apache.artemis groupId introduced when Artemis became an independent Apache top-level project at 2.50.0. The old org.apache.activemq coordinates end at a real 2.44.0 that is vulnerable to the entire batch; everything published there from 2.50.0 onward is a jar-less relocation stub. There is no Java 8 or Java 11 compatible release that clears these CVEs, a point Pentaho's remediation work spells out from the consumer side.

One thing the project did right on compatibility: the 2.39.0 notes state a Java 17 broker remains backward compatible with all previous clients, so clients and brokers do not have to move in the same change window on the client side.

ActiveMQ Artemis has no EOL policy, which means everything below HEAD is EOL

Artemis maintains no LTS branches and publishes no support window. Fixes ship in the next feature release, full stop. In the last five years there have been exactly two out-of-band patch releases for older lines: 2.19.1 for CVE-2022-23913 in early 2022, and the 2.31.1/2.31.2 bug fixes in late 2023. Everything else is "upgrade to latest," and latest keeps raising the floor: Java 11 at 2.20.0, Java 17 at 2.39.0, a replaced management console at 2.40.0, and the groupId change at 2.50.0.

So for a Java 8 or Java 11 shop, the upstream remediation path is: upgrade the JDK, change every Artemis dependency's groupId, migrate javax to Jakarta, absorb the console replacement and handshake changes, and upgrade every broker in the cluster in lockstep. That is a migration project with a budget and a timeline, not a dependency bump.

Which Sprint Boot versions are affected?  Every Spring Boot line, including the current one

Spring Boot pins one Artemis version per Boot minor through the artemis.version property, and does not move managed dependencies across major Artemis changes on maintenance lines. The pins below are verified against spring-boot-dependencies on Maven Central.

Three things to take from that table.

Boot 2.7 users are the hardest stranded. Artemis 2.57.0 is Jakarta-only and Java 17-only, so a Boot 2.7 application cannot consume it at all, no matter what version property it sets. The only upstream option is a Boot 3.x or 4.x migration first.

Even current Boot lines ship vulnerable. Boot 4.1 moved to the new groupId but pins 2.53.0, which is affected by all seven CVEs fixed in 2.57.0. Users on Boot 4.1 can override artemis.version to 2.57.0+ and absorb the behavior changes directly. On the org.apache.activemq-based lines (Boot 3.x and 4.0), whether an override to 2.57.0 even resolves depends on your build tool following the relocation POM: Maven does, with a warning, while Gradle does not and fails to resolve, so those builds must also change the groupId by hand.

And this is not just a broker problem. The affected ranges cover artemis-core-client and the JMS client artifacts, so Boot applications that only consume messages from a remote broker, the common case, are still exposed on the client-side handshake paths and will still be flagged by scanners.

Mitigation guidance

For Boot 2.7 users adopting NES, the change is one property pointing at the HeroDevs registry:

<properties>
  <artemis.version>2.19.1-artemis-server-2.19.4</artemis.version>
</properties>

NES v2.19.4 (released October 2, 2026) resolves CVE-2026-49364, CVE-2026-57967, CVE-2026-67593, CVE-2026-49362, CVE-2026-49363, and CVE-2026-75880 on the 2.19.x line, and NES 2.19.3 resolved CVE-2026-27446 in August. CVE-2026-57822 is not listed in the NES release notes, so treat its 2.19.x status as unconfirmed; it requires an authenticated client holding MANAGE permission, which narrows the exposure while that is resolved. The two Low entries, CVE-2026-40914 and CVE-2026-32642, are likewise outside the published NES fix list. Each directory entry carries a VEX document for scanner and compliance workflows.

Two operational notes before upgrading to NES v2.19.4, both inherited deliberately from the upstream fixes:

• Discovery is now disabled by default. A broker configured with any broadcast-group or discovery-group will log AMQ224097 and stay stopped until discovery is re-enabled with artemis.discovery.enabled=true or ARTEMIS_DISCOVERY_ENABLED=true. An embedded broker gets no exception from start(), so callers must check isStarted(). Re-enabling restores exactly the exposure CVE-2026-49364 describes, so do it only on a trusted network, or move the cluster to static connectors.
• Core downstream federation is deny-by-default. The CVE-2026-27446 fix adds a downstream-authorization attribute that is empty by default, so brokers using Core downstream federation must authorize roles or they will log AMQ224158 / AMQ224159 and refuse requests. That refusal is the fix working.

Related reading

Artemis is one instance of a pattern we track monthly: Spring Boot pins a dependency, the Boot line goes EOL, and the dependency keeps taking CVEs the pin will never receive. See Spring Boot managed dependencies still get CVEs after EOL: September 2026 patch round-up for the running series, and Spring Boot 3.5 is officially end of life for why the 3.5 row in the table above now reads the same as 3.0 through 3.4.

What the project did right

This is not a story about a neglected project. Artemis started hardening before the CVE wave landed: 2.54.0 (May 2026) began rejecting default cluster-user / cluster-password credentials outright, and 2.55.0 (June 2026) shipped a published threat model, a SECURITY.md, and an AGENTS.md explicitly described as helping both humans and AI agents produce higher-quality security reports. The six-fix 2.57.0 batch arrived in the releases immediately after.

A reasonable inference, and we label it as inference: AI-assisted vulnerability research is now reaching mature Java infrastructure projects at scale, and Artemis is a well-run project that saw it coming, prepared for it, and still shipped a decade's worth of advisories in nine months. The lesson for operators is that the support model, not project quality, determines your exposure. When fixes only ever ship at HEAD, everyone below HEAD is effectively end-of-life, whether the project uses that word or not.

Taking action

If your runtime and roadmap allow it, migrate to Artemis 2.57.0 or later under org.apache.artemis and treat it as the project it is: JDK floor, Jakarta namespace, build coordinates, console, and a lockstep cluster upgrade. Then audit two configuration states that are attack preconditions regardless of version: whether server discovery is enabled, and whether default cluster credentials are anywhere in your estate.

If you are on Spring Boot 2.7, or pinned anywhere on the dead org.apache.activemq line, there is no OSS fix available and none coming. NES for Apache ActiveMQ Artemis v2.19.4 resolves these vulnerabilities as a drop-in replacement for the exact version Boot 2.7 manages, and NES for Spring covers the EOL Boot lines around it, so you can secure what you run today and schedule the Jakarta and Java 17 migration on your own timeline, not a CVE's. Talk to HeroDevs about coverage for your Artemis estate.