CVE-2026-111822

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.

An authorization bypass vulnerability (CVE-2026-111822) has been identified in the Apache ActiveMQ Classic runtime configuration plugin, which allows authenticated users to keep sending messages to a destination after their write permission on it has been revoked. An existing connection keeps this access, including through a new anonymous producer, while fresh connections and new producers for that destination are denied.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects multiple versions of Apache ActiveMQ Classic.

Details

Module Info

• Product: Apache ActiveMQ Classic
• Affected packages: org.apache.activemq:apache-activemq, org.apache.activemq:activemq-runtime-config
• Affected versions: <5.19.12, >=6.0.0 <6.3.3
• GitHub repository: https://github.com/apache/activemq
• Published packages:
  • https://central.sonatype.com/artifact/org.apache.activemq/apache-activemq
  • https://central.sonatype.com/artifact/org.apache.activemq/activemq-runtime-config
• Package manager: Maven
• Fixed in:
  • OSS Apache ActiveMQ Classic 5.19.12, 6.3.3, 6.4.0
  • NES for ActiveMQ v5.16.13

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:activemq-runtime-config package, shipped in the org.apache.activemq:apache-activemq distribution, in multiple versions of Apache ActiveMQ Classic. It affects brokers that use the runtime configuration plugin to change authorization rules while the broker is running.

The broker's AuthorizationBroker caches the destinations each connection has already been allowed to write to. When a producer is created for a destination, or when a message is sent to a destination that is not yet in the cache, the broker checks the write ACLs and then records the destination in the connection's SecurityContext. Later sends to a cached destination skip the ACL check:

public void send(ProducerBrokerExchange producerExchange, Message messageSend) throws Exception {
    final SecurityContext securityContext = checkSecurityContext(producerExchange.getConnectionContext());

    if (!securityContext.isBrokerContext() && !securityContext.getAuthorizedWriteDests().containsValue(messageSend.getDestination())) {
        // write ACL check only runs on a cache miss
        ...
        securityContext.getAuthorizedWriteDests().put(messageSend.getDestination(), messageSend.getDestination());
    }

    super.send(producerExchange, messageSend);
}

When the runtime configuration plugin applies a changed authorization map, whether from the XML configuration (AuthorizationPluginProcessor.modify) or the Java API (JavaRuntimeConfigurationBroker.updateAuthorizationMap), it only replaces the map on the AuthorizationBroker:

public void modify(Object existing, Object candidate) {
    try {
        // replace authorization map - need exclusive write lock to total broker
        AuthorizationBroker authorizationBroker =
                (AuthorizationBroker) plugin.getBrokerService().getBroker().getAdaptor(AuthorizationBroker.class);

        authorizationBroker.setAuthorizationMap(fromDto(filter(candidate, DtoAuthorizationPlugin.Map.class)));
    } catch (Exception e) {
        plugin.info("failed to apply modified AuthorizationMap to AuthorizationBroker", e);
    }
}

Neither path clears the per-connection authorizedWriteDests caches, although AbstractAuthenticationBroker.refresh() exists for that purpose. The new map is therefore consulted only by new connections and by cache misses. A connection that wrote to a destination before an administrator revoked its write grant keeps the destination in its cache, so its existing producers, and any anonymous producer it creates later, can go on sending to that destination until the connection is closed.

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.

Credits

• hataehoon (finder)