Red Hat AMQ Broker CVE-2026-86404

The attacker must hold valid JMS client credentials with permission to publish messages to at least one queue or topic on the Artemis broker (PR:L per CVSS). The vulnerability is present in default broker configurations where no allow-list has been explicitly set - no additional misconfiguration or non-default feature enablement is required beyond the out-of-the-box state. Exploitation is limited by: (1) requirement for authenticated JMS access - unauthenticated network attackers cannot directly trigger deserialization; (2) a consuming application or service must call ObjectMessage.getObject() on the crafted message, introducing a timing dependency; (3) successful RCE also requires a viable deserialization gadget chain present in the broker's class path. The attack is not limited to a specific platform or OS.

The CVSS 8.8 score (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately captures the core risk: network-reachable, low-complexity exploitation requiring only JMS client-level authentication. Java deserialization gadget chains targeting libraries commonly present in enterprise Java class paths (Apache Commons Collections, Spring Framework, etc.) are extensively published and tooled, meaning the theoretical barrier to weaponization is low once access to the broker is obtained. EPSS score was not provided, and CISA KEV status is absent, so confirmed active exploitation cannot be asserted - but even a mid-sized municipal IT team in gdynia running JBoss EAP in its default configuration should treat this as urgent, given that default broker setups typically expose ObjectMessage support without any allow-list hardening. The scope-unchanged rating means impact is contained to the broker process itself, though on a co-hosted EAP node that process typically runs with application-server privileges. The primary limiting factor is the PR:L requirement - exploitation is gated on possessing valid JMS client credentials, which in practice are often shared across internal services and may be accessible to insider threats or lateral-movement scenarios.

An attacker who has obtained JMS client credentials - through credential stuffing, internal access, or lateral movement - connects to the Artemis broker over the network and publishes an ObjectMessage containing a pre-built Java deserialization gadget chain (e.g., targeting Apache Commons Collections). Upon a consumer calling ObjectMessage.getObject(), the broker's ObjectInputStreamWithClassLoader deserializes the payload without filtering, executing the embedded gadget chain and granting the attacker code execution as the broker process user. No public proof-of-concept targeting this specific configuration flaw has been identified, but generic Java deserialization exploit toolkits (ysoserial, marshalsec) are readily available.