CVE-2026-41044

Overview

Apache ActiveMQ Classic is an open-source, Java-based message broker. It fully supports JMS 1.1, partially supports Jakarta Messaging 3.1 and JMS 2.0, and accepts clients over OpenWire, AMQP, MQTT, and STOMP through pluggable transports such as TCP, SSL, NIO, and in-VM. Broker and client components are published as Maven artifacts under org.apache.activemq.

A remote code execution vulnerability (CVE-2026-41044) has been identified in the ActiveMQ broker's JMX management layer, which allows an authenticated attacker with access to the admin web console to run arbitrary code on the broker's JVM. The attacker plants a crafted broker name and then sends a message through the DestinationView MBean, which makes the broker load a remote Spring XML application context.

Per OWASP: Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data.

This issue affects multiple versions of ActiveMQ.

‍

Details

Module Info

• Product: ActiveMQ
• Affected packages: org.apache.activemq:activemq-broker, org.apache.activemq:activemq-all, org.apache.activemq:apache-activemq
• Affected versions: <5.19.6, >=6.0.0 <6.2.5
• GitHub repository: https://github.com/apache/activemq
• Published packages: https://central.sonatype.com/artifact/org.apache.activemq/activemq-broker, https://central.sonatype.com/artifact/org.apache.activemq/activemq-all, https://central.sonatype.com/artifact/org.apache.activemq/apache-activemq
• Package manager: Maven
• Fixed in:
• OSS ActiveMQ 5.19.6, 6.2.5
• NES for ActiveMQ v5.16.10

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:activemq-broker package in multiple versions of ActiveMQ. BrokerService.setBrokerName replaces any character outside [a-zA-Z0-9._\-:] before it stores a broker name. RegionBroker keeps its own mutable copy of the name, however, and its public setter stores whatever it is given:

private String brokerName;

public void setBrokerName(String brokerName) {
    this.brokerName = brokerName;
}

Through the admin web console, an authenticated user can set a broker name that skips the BrokerService check and carries an xbean binding. The DestinationView MBean then builds the connection URL for its internal producer by concatenating that name onto the vm:// scheme:

public String sendTextMessage(Map<String, String> headers, String body, String userName, @Sensitive String password) throws Exception {

    String brokerUrl = "vm://" + broker.getBrokerName();
    ActiveMQDestination dest = destination.getActiveMQDestination();

    ActiveMQConnectionFactory cf = new ActiveMQConnectionFactory(brokerUrl);
    Connection connection = null;
    try {
        connection = cf.createConnection(userName, password);

Because the broker name is not an inert identifier here, the injected text becomes part of the VM transport URI. When the next message is sent through DestinationView, the VM transport reads the attacker's xbean binding and creates a broker from a remote Spring XML file. Spring's ResourceXmlApplicationContext instantiates every singleton bean in that file before BrokerService validates the configuration, so bean factory methods such as Runtime.exec() run with the privileges of the broker's JVM.

‍

Mitigation

Only recent versions of Apache ActiveMQ Classic are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. For more information see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade ActiveMQ to a currently supported release that contains the fix, such as 5.19.6.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• jsjcw (finder)