CVE-2026-86404: EAP Artemis Deserialization Vulnerability

CVE-2026-86404 Overview

CVE-2026-86404 is an insecure deserialization vulnerability in Red Hat JBoss Enterprise Application Platform (EAP) affecting the embedded Apache ActiveMQ Artemis messaging component. The flaw resides in ObjectMessage.getObject(), which relies on ObjectInputStreamWithClassLoader to enforce class filtering through its checkSecurity() and isTrustedType() methods. Because both the allow-list and block-list are empty by default, isTrustedType() returns true for every class submitted for deserialization. Authenticated attackers with network access to a JMS endpoint can submit a crafted ObjectMessage payload and trigger arbitrary code execution during deserialization. The weakness is classified as [CWE-502] Deserialization of Untrusted Data.

Critical Impact
An authenticated attacker with access to an Artemis JMS destination can achieve remote code execution on the EAP server by delivering a malicious serialized Java object.

Affected Products

Red Hat JBoss Enterprise Application Platform (EAP) with embedded Apache ActiveMQ Artemis
Deployments using ObjectMessage with the default Artemis deserialization configuration
Applications relying on ObjectInputStreamWithClassLoader without configured allow-list entries

Discovery Timeline

2026-09-07 - CVE-2026-86404 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86404

Vulnerability Analysis

The vulnerability originates in how Artemis validates classes during Java deserialization of JMS ObjectMessage payloads. ObjectInputStreamWithClassLoader was designed to restrict deserialization to trusted classes through a checkSecurity() gate. That gate delegates to isTrustedType(), which evaluates the configured allow-list and block-list. When the allow-list is empty, the method treats the absence of entries as permission for every class rather than as a deny-by-default posture. This inverted default converts a security control into a pass-through.

Once filtering is bypassed, deserialization proceeds through standard Java gadget chains. Attackers can leverage any exploitable class present on the EAP classpath, including well-known Apache Commons Collections or similar gadgets, to achieve arbitrary code execution in the context of the application server process. The network-reachable nature of JMS brokers and the availability of low-privilege authenticated access broaden the exposure across enterprise messaging deployments.

Root Cause

The root cause is an insecure default configuration in the class-filtering logic. isTrustedType() returns true when the allow-list size equals zero, effectively disabling the safeguard for every deployment that does not explicitly enumerate trusted classes. Administrators who assume a deny-by-default model inherit an allow-all policy silently.

Attack Vector

Exploitation requires network access to an Artemis JMS endpoint and valid credentials to send messages. The attacker publishes a JMS ObjectMessage containing a serialized gadget chain to a queue or topic the target consumer reads. When the consumer calls getObject(), ObjectInputStreamWithClassLoader deserializes the payload without meaningful class filtering, executing the embedded gadget chain. See the Red Hat CVE-2026-86404 Details and Red Hat Bug Report #2477930 for further technical background.

Detection Methods for CVE-2026-86404

Indicators of Compromise

Unexpected child processes spawned by the EAP JVM, particularly shells, curl, wget, or scripting interpreters
Artemis broker logs showing consumption of ObjectMessage payloads from untrusted producers or unusual sources
Java stack traces referencing ObjectInputStreamWithClassLoader.checkSecurity alongside gadget classes such as InvokerTransformer or TemplatesImpl

Detection Strategies

Inspect Artemis broker configuration for empty deserializationAllowList and deserializationBlockList properties on connection factories and acceptors
Hunt for JMS traffic that includes serialized Java streams by matching the AC ED 00 05 magic bytes on message bodies
Correlate authentication events on JMS listeners with subsequent process creation or outbound network activity from the EAP host

Monitoring Recommendations

Enable verbose logging in Artemis for ObjectMessage handling and forward broker logs to a centralized analytics platform
Monitor EAP host telemetry for anomalous process lineage and unexpected outbound connections from the application server user
Track configuration drift on broker.xml and connection factory settings to detect removal of allow-list entries

How to Mitigate CVE-2026-86404

Immediate Actions Required

Apply the fixes referenced in Red Hat Security Advisory RHSA-2026:53644 to all affected EAP instances
Configure an explicit deserializationAllowList containing only the fully qualified class names required by the application
Restrict network access to Artemis acceptors so only trusted producers and consumers can authenticate
Rotate JMS credentials and audit recent authenticated sessions against messaging endpoints

Patch Information

Red Hat has published fixes through Red Hat Security Advisory RHSA-2026:53644. Review the advisory for the exact package versions applicable to each EAP release channel and apply updates through the standard subscription-manager or patch management workflow. Additional context is available in the Red Hat CVE-2026-86404 Details page.

Workarounds

Disable ObjectMessage usage where possible and migrate producers and consumers to TextMessage, BytesMessage, or MapMessage
Populate deserializationAllowList with a strict set of trusted classes and add high-risk gadget classes to deserializationBlockList
Isolate Artemis brokers on segmented networks and enforce mutual TLS on all JMS acceptors

bash

# Configuration example: restrict Artemis deserialization on the connection factory
<connection-factory name="RemoteConnectionFactory"
    entries="java:jboss/exported/jms/RemoteConnectionFactory"
    connectors="http-connector"
    deserialization-allow-list="com.example.model.Order,com.example.model.Customer"
    deserialization-block-list="org.apache.commons.collections.functors.InvokerTransformer"/>