Bug 2478013 (CVE-2026-49364) - CVE-2026-49364 wildfly-messaging-activemq-subsystem: artemis-server: jgroups: artemis cluster password leak via jgroups spoof
Summary: CVE-2026-49364 wildfly-messaging-activemq-subsystem: artemis-server: jgroups:...
Keywords:
Status: NEW
Alias: CVE-2026-49364
Product: Security Response
Classification: Other
Component: vulnerability-draft
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-15 19:39 UTC by OSIDB Bzimport
Modified: 2026-09-22 15:35 UTC (History)
44 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2026:66488 0 None None None 2026-09-10 16:35:19 UTC
Red Hat Product Errata RHSA-2026:66545 0 None None None 2026-09-10 23:23:31 UTC
Red Hat Product Errata RHSA-2026:70228 0 None None None 2026-09-22 12:56:13 UTC
Red Hat Product Errata RHSA-2026:70229 0 None None None 2026-09-22 13:00:46 UTC
Red Hat Product Errata RHSA-2026:70230 0 None None None 2026-09-22 12:58:41 UTC
Red Hat Product Errata RHSA-2026:70277 0 None None None 2026-09-22 15:35:48 UTC

Description OSIDB Bzimport 2026-05-15 19:39:04 UTC
initial report:
Auth Bypass — Artemis cluster-password leaked to JGroups-spoofed peer → broker MANAGE takeover (JBoss EAP)

Composite authentication bypass: an attacker on the JGroups cluster backplane spoofs a discovery response to join the cluster, and the legitimate Artemis broker transmits its cluster-password in plaintext during the handshake; with this password the attacker authenticates to the CORE cluster channel via :8080 from any network position, gaining full MANAGE-level broker authority including message injection, journal access, and topology manipulation.
findings/jboss-eap_35.md

-----
secarx findings:
  Prerequisites for exploitation:

  1. JGroups network access: The attacker must be on the same multicast-reachable network segment as the JGroups private interface. In default configurations, the
  private interface binds to 127.0.0.1, so the attacker would need the administrator to have changed jboss.bind.address.private to a routable address (which is required
  for actual multi-node clustering to work). In any real HA deployment, this address is set to a routable interface.
  2. Cluster password capture: If the administrator has not set an explicit cluster-password (left as "CHANGE ME!!"), each node generates a different random UUID and
  clustering is broken. In any functioning HA deployment, the administrator has set a shared password. When the legitimate broker initiates a ClusterConnectionBridge to
  the attacker's spoofed node, the CreateSessionMessage containing this shared password is sent in plaintext. The attacker captures it passively.
  3. Port 8080 reachability: The attacker must have TCP access to port 8080 on any cluster member. This port is the standard application HTTP port and is typically
  accessible from client networks.

  Attack flow:

  Step 1 — The attacker responds to JGroups PING/MPING discovery on the cluster backplane, advertising a spoofed broker endpoint. No AUTH is checked.

  Step 2 — A legitimate broker node establishes a ClusterConnectionBridge to the attacker's spoofed endpoint, sending a CreateSessionMessage containing the cluster user
  and password in plaintext. The attacker captures the password.

  Step 3 — From any network position that can reach port 8080, the attacker performs an HTTP upgrade to the CORE protocol (no authentication required for the upgrade
  itself).

  Step 4 — The attacker sends a CreateSessionMessage with username=ACTIVEMQ.CLUSTER.ADMIN.USER and password=the captured value. Artemis SecurityStoreImpl authenticates
  this internally, bypassing Elytron and all RBAC checks.

  Step 5 — The attacker has full MANAGE-level authority: message injection and consumption on all addresses, queue creation and deletion, journal access through
  management operations, and topology manipulation.


There are some major network level pre-requisites and because of that it should be considered as Important but not Critical. Should be filed as a new CVE and trackers should be created as EAP 8.0 and 8.1 are in full support and should fix this CVE.

Comment 3 errata-xmlrpc 2026-09-10 16:35:17 UTC
This issue has been addressed in the following products:

  Red Hat AMQ Broker 7.14.1

Via RHSA-2026:66488 https://access.redhat.com/errata/RHSA-2026:66488

Comment 4 errata-xmlrpc 2026-09-10 23:23:29 UTC
This issue has been addressed in the following products:

  Red Hat AMQ Broker 7.13.6

Via RHSA-2026:66545 https://access.redhat.com/errata/RHSA-2026:66545

Comment 5 Jon Orris 2026-09-22 12:56:11 UTC
This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 8

Via RHSA-2026:70228 https://access.redhat.com/errata/RHSA-2026:70228

Comment 6 Jon Orris 2026-09-22 12:58:38 UTC
This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 10

Via RHSA-2026:70230 https://access.redhat.com/errata/RHSA-2026:70230

Comment 7 Jon Orris 2026-09-22 13:00:43 UTC
This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform 8.1 for RHEL 9

Via RHSA-2026:70229 https://access.redhat.com/errata/RHSA-2026:70229

Comment 8 Jon Orris 2026-09-22 15:35:45 UTC
This issue has been addressed in the following products:

  Red Hat JBoss Enterprise Application Platform 8.1

Via RHSA-2026:70277 https://access.redhat.com/errata/RHSA-2026:70277


Note You need to log in before you can comment on or make changes to this bug.