CVE-2026-86404: Artemis-server: artemis-jms-client: artemis-core-client: undertow-core: wildfly-messaging-activemq-subsystem: artemis messaging handlers in red hat eap permit deserialization by default

submitted through leadership channels

NOTE this flaw was initially reported as a chained attack of 2 distinct vulns: missing authentication in Artemis federation, and permissive deserialization in Artemis messaging. This flaw addresses the deserialization portion; the missing auth is covered in CVE-2026-27446.

initial data: RCE — pre-auth Artemis federation fake-upstream routes ObjectMessage into unfiltered MDB getObject() (JBoss EAP)

Unauthenticated remote code execution: by exploiting the unauthenticated Artemis federation handler (#13) to register a fake upstream broker, an attacker injects a serialized ObjectMessage into an MDB's queue; the MDB's getObject() call deserializes it through an unfiltered ObjectInputStream with deployment-classloader gadget reach, achieving OS command execution as the EAP process uid.

findings/jboss-eap14.md

----- secarx findings: FINDING 1: Unauthenticated RCE via Artemis federation fake-upstream + ObjectMessage deserialization

CLAIM: By exploiting the unauthenticated Artemis federation handler to register a fake upstream broker, an attacker injects a serialized ObjectMessage into an MDB's queue; the MDB's getObject() call deserializes it through an unfiltered ObjectInputStream with deployment-classloader gadget reach, achieving OS command execution as the EAP process uid.

VERDICT: PARTIALLY TRUE— the federation bypass is real (CVE-2026-27446), the deserialization concern is valid but the "unfiltered ObjectInputStream" characterization is technically wrong.

WHAT IS ACCURATE:

1. The federation handler is unauthenticated. CoreProtocolManager.createConnectionEntry() registers a LocalChannelHandler on CHANNELID.FEDERATION (channel 4) immediately when a connection is created, before any authentication. The handler processes FEDERATIONDOWNSTREAMCONNECT (packet type -16) by extracting a FederationDownstreamConfiguration from the attacker's message and calling server.getFederationManager().deploy() to dynamically create a federation upstream connection back to the attacker. No authentication or authorization check occurs at any point in this flow. This is exactly CVE-2026-27446. 2. The WildFly/EAP messaging subsystem does not expose or configure federation, but the federation code is fully present and active in the Artemis server JAR. The FederationManager is instantiated regardless of whether federation is configured in the management model. The handler is registered on every CORE protocol connection. 3. Once federation is established to an attacker-controlled broker, the attacker can inject messages (including ObjectMessages) into any federated queue on the target broker. 4. Default deserialization configuration is permissive. ObjectMessage.getObject() uses ObjectInputStreamWithClassLoader, which implements allow-list/block-list filtering via its checkSecurity()/isTrustedType() method. However, by default both allow-list and block-list are empty. When the allow-list is empty (size == 0), isTrustedType() returns true for ALL classes. This means all classes are deserializable by default.

WHAT IS INACCURATE:

1. "unfiltered ObjectInputStream" — ObjectMessage deserialization does NOT use raw ObjectInputStream. It uses ObjectInputStreamWithClassLoader, a custom subclass that overrides resolveClass() with class filtering. The filtering mechanism exists but is configured to allow everything by default. 2. "deployment-classloader gadget reach" — this is plausible but not guaranteed. The deserialization uses the thread context classloader, which in an MDB context would be the deployment classloader. Gadget chains would need to be present in the deployment's classloader scope (including EAP modules visible to the deployment).

EXPLOITABILITY — EAP 7.4.23: TRUE POSITIVE - Federation handler is present and unauthenticated on every CORE protocol connection - CORE protocol is accessible via HTTP upgrade on port 8080 (default) or direct acceptor - Default deserialization allows all classes - Mitigation available: deserialization-white-list/deserialization-black-list on pooled-connection-factory

EXPLOITABILITY — EAP 8.1.0: TRUE POSITIVE - Same federation handler code, same unauthenticated path - Same default-permissive deserialization - Mitigation available: deserialization-allow-list/deserialization-block-list on pooled-connection-factory

In summary: - CVE-2026-27446 alone = Important (message injection/exfiltration, no code execution) - CVE-2026-27446 + default-permissive deserialization = Critical (achieves code execution)

If you chain CVE-2026-27446 with the default-permissive ObjectMessage deserialization, actual OS command execution can be achieved.

My assessment: CRITICAL.

This can be mitigated by fixing CVE-2026-27446, Looks like this will be fixed in 8.1.6 (about to release) but for JBoss EAP 7.4, tracker was closed as this is an important impact and 7.4 is in ELS-1 where only critical fixes are provided.

Need to file a new Critical CVE and should be fixed in JBoss EAP 7.4, 8.0 and 8.1

The additional fix needed (after fixing CVE-2026-27446):

Configure a restrictive deserialization-allow-list on every pooled-connection-factory resource. For example, if your MDBs only expect to receive objects of type com.yourapp.OrderEvent, set the allow-list to "com.yourapp". This switches ObjectInputStreamWithClassLoader from "allow everything" to "deny by default, allow only listed classes." With this in place, even if an attacker injects a malicious ObjectMessage through any vector, the deserialization of gadget chain classes is blocked.

— Red Hat