CVE-2026-86404 in AMQ Broker
Summary
by MITRE • 09/07/2026
EAP's Artemis deserialization configuration permits deserialization by default. 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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability in EAP's Artemis messaging component stems from a critical misconfiguration of its Java Object Deserialization mechanism, specifically within the handling of JMS ObjectMessage payloads. When an application receives an ObjectMessage, it invokes getObject() to retrieve the serialized object contained within the message body. This process relies on a custom implementation called ObjectInputStreamWithClassLoader, which is designed to provide security through type filtering mechanisms known as allow-lists and block-lists. The intent of these filters is to restrict deserialization to only those classes that are explicitly trusted or safe for execution, thereby preventing attackers from exploiting unsafe deserialization patterns such as gadget chain attacks.
However, the default configuration presents a severe security flaw because both the allow-list and the block-list are initialized as empty collections. In the logic governing the checkSecurity() method of ObjectInputStreamWithClassLoader, there is a specific conditional behavior tied to the state of these lists. When the allow-list has zero entries, meaning it is effectively empty, the system interprets this absence not as an error or a default-deny stance, but rather as a signal that no restrictions should be applied. Consequently, the isTrustedType() method returns true for every single class encountered during deserialization regardless of its origin or nature. This logic flaw transforms what was intended to be a restrictive security control into a permissive one, effectively disabling protection against malicious object injection.
From an operational perspective, this vulnerability allows any client with access to the Artemis broker to inject arbitrary Java objects that will be fully instantiated and executed by the server process. An attacker can craft a serialized payload containing dangerous gadget chains, such as those involving common libraries like Commons Collections or Spring Framework, which trigger remote code execution upon deserialization. Since the filtering mechanism is bypassed entirely due to the empty allow-list configuration, there are no safeguards to prevent these malicious objects from being processed. This represents a classic case of insecure default configurations where security features exist but fail to activate under standard settings, leaving systems exposed to high-severity attacks without requiring any complex exploitation techniques beyond basic message submission capabilities.
This issue aligns with CWE-502, which describes Deserialization of Untrusted Data, as the system fails to validate or restrict the types of objects being deserialized from untrusted sources. Furthermore, it relates to CWE-16 regarding Configuration Errors, specifically where default settings do not adhere to security best practices by failing to enforce a deny-by-default policy for sensitive operations like object instantiation. In terms of attack vectors, this vulnerability facilitates Remote Code Execution (RCE) and can be mapped to MITRE ATT&CK techniques involving Taint Analysis or specific deserialization gadget chains depending on the available libraries in the classpath.
To mitigate this risk, it is imperative that administrators explicitly configure a robust allow-list within the Artemis configuration files before deploying the service in any production environment. This list must contain only the specific classes required by legitimate business logic for object messaging, ensuring that all other types are rejected during deserialization attempts. Alternatively, if dynamic class loading is not strictly necessary, disabling ObjectMessage support entirely or switching to a safer data format like JSON or XML can eliminate the attack surface associated with Java serialization altogether. Regular security audits should verify that these configuration parameters are correctly set and monitored for changes, ensuring that the default permissive behavior does not persist in live environments where external inputs may be processed by the messaging broker.