CVE-2026-101292 in AMQ Broker
Summary
by MITRE • 09/28/2026
Apache ActiveMQ Artemis before 2.34.0 contains an unsafe reflection vulnerability in FederationStreamConnectMessage.getFederationPolicy(). The method calls Class.forName(clazz).getConstructor().newInstance() where clazz is read directly from the CORE protocol wire buffer without type validation. An authenticated federation peer can send a FEDERATION_DOWNSTREAM_CONNECT packet with a crafted class name, causing the broker to load and instantiate arbitrary classes visible to the Artemis module classloader. Static initializers (<clinit>) and no-argument constructors (<init>()) execute as side effects before the type cast, enabling denial of service via system-property poisoning, out-of-memory conditions via classloading, or broker state manipulation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Apache ActiveMQ Artemis prior to version 2.34.0 represents a critical unsafe reflection flaw within the FederationStreamConnectMessage component. Specifically, the getFederationPolicy method invokes Class.forName followed by constructor instantiation using user-supplied input derived directly from the CORE protocol wire buffer. This implementation fails to perform any form of type validation or allowlisting on the class name provided in the FEDERATION_DOWNSTREAM_CONNECT packet. Consequently, an authenticated federation peer can manipulate the broker's behavior by supplying a crafted class name that triggers the loading and instantiation of arbitrary classes available within the Artemis module classloader environment. This lack of input sanitization creates a direct pathway for attackers to execute code or trigger side effects during the reflection process, fundamentally undermining the security boundary between the message protocol layer and the underlying Java runtime.
The operational impact of this vulnerability is severe due to the execution context in which these classes are loaded. When Class.forName is called with an attacker-controlled string, the JVM attempts to load the specified class into memory. If the targeted class contains static initializers or no-argument constructors that perform side effects such as modifying system properties, allocating large amounts of heap memory, or altering broker state variables, these actions occur immediately upon instantiation before any type casting takes place. This mechanism allows for denial-of-service attacks through out-of-memory conditions caused by excessive classloading or resource exhaustion via malicious static blocks. Furthermore, attackers can poison system properties to alter the runtime environment's configuration, potentially leading to further privilege escalation or persistent state manipulation that compromises the integrity of the message broker service.
From a classification perspective, this vulnerability aligns with CWE-470 which describes unsafe reflection where user input is used directly in reflective calls without proper validation. The attack vector leverages authenticated access to exploit this flaw, mapping closely to MITRE ATT&CK technique T1621 known as Runtime Resource Hijacking or potentially T1539 if the goal involves stealing credentials via system property manipulation. The exploitation requires authentication, which limits the scope of potential attackers but does not diminish the severity given that federation peers are typically trusted entities within a distributed messaging architecture. An attacker with valid federation credentials can effectively take control over the broker's execution flow by forcing it to load and execute malicious or destabilizing classes.
Mitigation strategies must prioritize immediate patching to version 2.34.0 or later where this reflection logic has been secured. In environments where upgrading is not immediately feasible, network-level controls should be implemented to restrict access to the federation port exclusively to known and trusted IP addresses associated with legitimate federation peers. Additionally, implementing strict allowlists for class names within any custom security managers or policy files can provide a secondary layer of defense by preventing the loading of unexpected classes even if reflection is attempted. Security teams should also monitor broker logs for unusual patterns in FEDERATION_DOWNSTREAM_CONNECT packets and ensure that system properties critical to application stability are protected from modification during runtime operations involving untrusted inputs.