REDHAT-BUG-2478013: High severity Red Hat JBoss EAP vulnerability

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-eap35.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.