CVE-2026-49434

Overview

Apache ActiveMQ Classic is an open-source Java message broker that provides asynchronous messaging for applications. It supports JMS 1.1 and multiple wire protocols, including OpenWire, AMQP, MQTT and STOMP. Broker and client components are published as Maven artifacts under org.apache.activemq. ActiveMQ Classic is distinct from Apache ActiveMQ Artemis, which has its own broker implementation and release lines.

A resource injection vulnerability (CVE-2026-49434) has been identified in the LDAP network connector of the Apache ActiveMQ Classic broker, which allows attackers who can publish or modify LDAP entries matching the configured searchBase and searchFilter to instantiate denied transports inside the broker JVM. This can be used to fetch an attacker-controlled URL and spawn a second BrokerService inside the same JVM.

Per OWASP: This attack consists of changing resource identifiers used by an application in order to perform a malicious task. When an application defines a resource type or location based on user input, such as a file name or port number, this data can be manipulated to execute or access different resources.

This issue affects multiple versions of Apache ActiveMQ Classic.

‍

Details

Module Info

• Product: Apache ActiveMQ Classic
• Affected packages: org.apache.activemq:activemq-broker, org.apache.activemq:apache-activemq, org.apache.activemq:activemq-all
• Affected versions: <5.19.8, >=6.0.0 <6.2.7
• 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/apache-activemq, https://central.sonatype.com/artifact/org.apache.activemq/activemq-all
• Package manager: Maven
• Fixed in:
  • OSS Apache ActiveMQ Classic 5.19.8, 6.2.7
  • NES for ActiveMQ v5.16.12

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:activemq-broker package in multiple versions of Apache ActiveMQ Classic. LdapNetworkConnector discovers network connectors by searching an LDAP directory with the configured searchBase and searchFilter. For every matching entry, toURI builds a connector URI directly from the entry's ipserviceprotocol, iphostnumber and ipserviceport attributes:

protected URI toURI(SearchResult result) throws Exception {
    Attributes attributes = result.getAttributes();
    String address = (String) attributes.get("iphostnumber").get();
    String port = (String) attributes.get("ipserviceport").get();
    String protocol = (String) attributes.get("ipserviceprotocol").get();
    URI connectorURI = new URI("static:(" + protocol + "://" + address + ":" + port + ")");
    LOG.debug("retrieved URI from SearchResult [{}]", connectorURI);
    return connectorURI;
}

addConnector then hands that URI to the broker without checking which transport scheme it names:

URI connectorURI = toURI(result);
...
NetworkConnector connector = getBrokerService().addNetworkConnector(connectorURI);

addConnector runs for each result of the initial search and, when the persistent search listener is enabled, again whenever a matching entry is added or changed. The transport scheme, host and port therefore come entirely from directory data, and nothing restricts which transports the resulting network connector may use. An attacker who can write a matching LDAP entry can set ipserviceprotocol to a transport that should never be reachable from directory data, such as vm, http or failover, and the broker instantiates it. This can be used to make the broker fetch an attacker-controlled URL and start a second BrokerService, configured from remote properties, inside the same JVM.

‍

Mitigation

Inactive versions of Apache ActiveMQ Classic are End-of-Life and will not receive updates to address this issue. For more information, see here.

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

• Upgrade affected applications to a currently supported release of Apache ActiveMQ Classic that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.