HeroDevs
Visit NES for Apache ActiveMQ Artemis Home Page

NES for ActiveMQ Artemis 2.19.x Release Notes

3 versions

Comprehensive release notes and changelog for NES for ActiveMQ Artemis 2.19.x, including security patches, bug fixes, and feature updates across all supported versions.

Oct 2, 2026
Latest: 2.19.4
9 Patched Vulnerabilities
VEX Statements

October 2026

2.19.4

Released Oct 2, 2026
CVE-2026-49364
CVE-2026-57967
CVE-2026-67593
CVE-2026-49362
CVE-2026-49363
1 More
Full Version: 
2.19.1-artemis-server-2.19.4

Security Fixes

  • CVE-2026-49364 (Critical) - Cluster credential exposure through discovery. A broker that found its cluster peers through a discovery group trusted every broadcast it received, because nothing authenticates the sender. An attacker who could broadcast on the discovery network could advertise a node of their own, and the cluster connection would open a bridge to it using the configured cluster user and password. Server discovery is now disabled by default. See Breaking Changes before upgrading. Fixed upstream in 2.57.0.
  • CVE-2026-57967 (Critical) - Missing authentication in CORE session reattachment. The broker accepted a REATTACH_SESSION request on a connection before it authenticated, so an unauthenticated connection could take over another client's authenticated session. Reattachment now requires an authenticated connection. Fixed upstream in 2.57.0.
  • CVE-2026-67593 (Critical) - Missing authentication for queue deletion in the OpenWire protocol handler. A client could open an OpenWire connection, send a single RemoveSubscriptionInfo command before authenticating, and make the broker delete a queue it named. An authenticated client could also remove another client's subscriptions. The broker now rejects OpenWire commands until the connection authenticates, and checks subscription removals against the connection's own identity. The fix ships in artemis-openwire-protocol; see Notes. Fixed upstream in 2.57.0.
  • CVE-2026-49362 (High) - Missing authentication for queue creation in the CORE protocol handler. An unauthenticated client could send CREATE_QUEUE packets on the session-creation channel and make the broker create durable queues of its choosing. The broker no longer handles CREATE_QUEUE on that channel. Fixed upstream in 2.57.0.
  • CVE-2026-49363 (High) - Cluster topology disclosure before authentication. An unauthenticated client could read the cluster topology, including every member and connector configuration. When security-enabled=true, the broker now withholds the other members and every connector until the connection authenticates, then delivers the full topology automatically. Fixed upstream in 2.57.0.
  • CVE-2026-75880 (Medium) - Regular expression denial of service in message selector LIKE wildcards. A consumer could supply a JMS selector whose LIKE pattern held enough % wildcards to cause excessive regular-expression backtracking, which the broker repeats for every message it evaluates. Patterns are now limited to five % wildcards. See Breaking Changes before upgrading. Fixed upstream in 2.57.0.

Breaking Changes

  • Server discovery is disabled by default. The CVE-2026-49364 fix changes a default, and a broker it affects doesn't start. A broker configured with any <broadcast-group> or <discovery-group> logs AMQ224097: Failed to start server, with AMQ229262 or AMQ229263 as the cause, and stays stopped. A broadcast group alone is enough to trigger this.
    Before upgrading, check each broker's configuration for those two elements. To keep using discovery, re-enable it on each broker with the system property artemis.discovery.enabled=true or the environment variable ARTEMIS_DISCOVERY_ENABLED=true. New instances can be generated with artemis create --discovery-enabled, which adds the property for you. Re-enabling restores exactly the exposure the CVE describes, so do it only on a trusted network. The alternative is to switch the cluster to static connectors.
    Two failures are easy to miss. An application that embeds the broker gets no exception: start() returns normally and the server stays stopped, so check isStarted() after starting it. And Core clients that use a discovery-based locator (UDP or JGroups) now fail with AMQ219070 instead of falling back to static connectors.
  • LIKE selectors are limited to five % wildcards. The CVE-2026-75880 fix rejects a LIKE pattern with more than five distinct % wildcards, counting consecutive wildcards such as %%% as one. A pattern that worked before can now fail with Invalid LIKE pattern: too many '%' wildcards (max 5, found N).
    The broker checks this wherever it parses a selector, including at startup, when it reloads persisted filters from the journal. So a durable subscription or queue filter it accepted before the upgrade can stop it starting afterwards. Before upgrading, check persisted durable-subscription and queue filters for LIKE patterns with more than five wildcards. You can raise the limit with the system property org.apache.activemq.artemis.selector.maxWildcards or the environment variable ARTEMIS_SELECTOR_MAX_WILDCARDS, but each step up re-opens part of the exposure.

Notes

  • The CVE-2026-67593 fix ships in artemis-openwire-protocol, which is published for this line from 2.19.4. A broker that loads the OpenWire protocol must upgrade that artifact to 2.19.1-artemis-server-2.19.4. Upgrading artemis-server alone doesn't apply the fix, because artemis-server doesn't depend on the OpenWire module.
  • The CVE-2026-49363 fix leaves one thing visible before authentication: the connected broker's own node ID. An unauthenticated client can learn the ID of each broker it reaches, but nothing about the rest of the cluster. Upstream sends a synthetic ID instead. This line doesn't, because Core clients released before the change would adopt the synthetic ID as the broker's identity, and connections to two different brokers could then look like the same XA resource manager.
  • The CVE-2026-49363 fix applies only when security-enabled=true; a broker without security is unchanged. Core clients authenticate during the handshake with the credentials configured on the locator, so they need no code change. The handshake uses a new CONNECT packet on packet IDs -4 and -5, which replaces the failover check and keeps CHECK_FOR_FAILOVER as a deprecated alias. A client that omits the new fields falls back to authenticating at session creation. For a rolling upgrade, you can restore the previous behaviour on a CORE acceptor with coreConnectionSecurityEnabled=false, for example tcp://0.0.0.0:61616?coreConnectionSecurityEnabled=false. That restores the disclosure the CVE describes, so remove it once the upgrade is done.
  • The CVE-2026-75880 wildcard limit reduces the risk but doesn't remove it. A pattern at the limit, such as %a%a%a%a%aZ, is still accepted and can take seconds to evaluate against a long value, so a client that supplies selectors can still impose some CPU cost.
  • The CVE-2026-49362 fix removes CREATE_QUEUE handling from the session-creation channel outright, so authenticated peers lose it too. No supported client uses it, because the Core client sends CREATE_QUEUE on the per-session channel, which is unchanged. A pre-2.x peer that relied on that channel to create replicated store-and-forward queues will stop having them created without any error on its side; the broker logs invalidPacket instead.
  • Each of these fixes landed upstream in 2.57.0, which upstream publishes under the org.apache.artemis groupId. No fixed release exists under org.apache.activemq.

August 2026

2.19.3

Released Aug 12, 2026
CVE-2026-27446
CVE-2022-35278
CVE-2025-27427
Full Version: 
2.19.1-artemis-server-2.19.3

Security Fixes

  • CVE-2026-27446 (Critical) - Missing authentication for critical function. An unauthenticated attacker could send a Core protocol federation downstream request and make the broker open an outbound federation connection to a broker they control, enabling message injection into and exfiltration from any queue. Downstream federation requests are now authenticated and authorized. Fixed upstream in 2.52.0, which upstream publishes under the org.apache.artemis groupId; no fixed release exists under org.apache.activemq.
  • CVE-2022-35278 (Medium) - HTML injection in the web console. An address or queue whose name contained HTML was rendered as markup, allowing an attacker to display misleading content or link an operator to a malicious URL. Table cells now render names as text. Fixed upstream in 2.24.0.
  • CVE-2025-27427 (Low) - A user without create-address permission could modify an address routing type. The routing type is now checked when a queue is created. Fixed upstream in 2.40.0.
  • Stored cross-site scripting in the web console's message-browse view (High; no CVE assigned; identified by HeroDevs). The Original Queue and Validated User columns rendered message properties as HTML without sanitization, so unlike the sanitized columns covered by CVE-2022-35278 they could execute script. Because the broker copies a queue's name verbatim into the Original Queue property when a message is dead-lettered, a queue named with a payload could run script in the browser of any operator viewing that dead-letter queue. All columns in that view now render as text. This issue has no upstream fix; upstream removed the affected console in 2.40.0 in favour of a separate console project, so every upstream release from 2.24.0 through 2.39.x remains exposed.

Breaking Changes

  • Core downstream federation is now deny-by-default. The CVE-2026-27446 fix adds a downstream-authorization attribute on the federations element, listing the roles permitted to deploy federation on the broker. It is empty by default, so a broker with security enabled refuses every incoming downstream federation request until roles are authorized. That refusal is the fix - these requests were previously not authorized at all.
    Deployments using Core downstream federation with security enabled will stop federating after upgrading until the roles are configured on the downstream broker:
    <!-- the user configured on the upstream broker must be in this role -->
<federations downstream-authorization="federation_role">
   ...
</federations>

    A broker with security disabled is unaffected, as are upstream, address and queue federation configured in the usual upstream-initiated direction.

Notes

  • Four log messages record the outcome of each downstream federation request, using the same identifiers as upstream so output correlates across versions: AMQ224158 (peer not authenticated) and AMQ224159 (user not in an authorized role) are warnings; AMQ224160 (federation deployed) and AMQ224161 (connection closed, federation undeployed) are informational. Seeing AMQ224158 or AMQ224159 after upgrading is the signal that downstream-authorization needs configuring.
  • The two web console fixes ship in the console web application, built from the artemis-hawtio module of the tagged source. That module is not published as a Maven artifact, so neither fix is obtainable from any of the artifacts listed under Published Maven Packages - deployments that run the broker distribution and its console need the console rebuilt from this release. Applications that consume only the client and server libraries were never exposed to either issue.

2.19.2

Released Aug 11, 2026
Full Version: 
2.19.1-artemis-server-2.19.2

Notes

  • This release originates from the open-source Apache ActiveMQ Artemis project forked by HeroDevs. It encompasses modifications implemented by HeroDevs to ensure successful framework builds.
  • This is the initial supported baseline for the 2.19.x line. It is functionally identical to upstream 2.19.1, with no behavioral changes, and contains no vulnerability patches. Security fixes are delivered in subsequent releases on this line.
  • Upstream ended maintenance of the 2.19 line at 2.19.1; the Apache project ships from a single active line and maintains no 2.19 branch.

Full Version: 2.19.1-artemis-server-2.19.2

Stay in the loop

~/herodevs-spring-framework-support

Open Source Support

When official support ends, we're just getting started.