EOL Fix Available | CVE-2025-27427

Overview

Apache ActiveMQ Artemis is an open-source, asynchronous messaging broker supporting the JMS, AMQP, MQTT, STOMP and Core protocols. It is widely deployed as the messaging backbone of Java applications, including as the embedded broker used by Spring Boot. An address is the destination messages are sent to, and it declares which routing types it supports, ANYCAST for point-to-point delivery, MULTICAST for publish-subscribe, or both.

An authorization bypass vulnerability (CVE-2025-27427) has been identified in Apache ActiveMQ Artemis, which allows attackers holding queue-creation permissions but not the create-address permission to change which routing types an existing address supports.

Per OWASP: access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others; these checks are performed after authentication, and govern what authorized users are allowed to do.

This issue affects multiple versions of Apache ActiveMQ Artemis.

Details

Module Info

Product: Apache ActiveMQ Artemis
Affected packages: org.apache.activemq:artemis-server
Affected versions: >=2.0.0 <=2.39.0
GitHub repository: https://github.com/apache/artemis
Published packages: https://central.sonatype.com/artifact/org.apache.activemq/artemis-server
Package manager: Maven
Fixed in: NES for ActiveMQ Artemis 2.19.1-artemis-server-2.19.3

Vulnerability Info

This Low-severity vulnerability is found in the org.apache.activemq:artemis-server package in multiple versions of Apache ActiveMQ Artemis. When creating a queue, the broker checked the create-address permission only if the address did not already exist:

AddressSettings as = server.getAddressSettingsRepository().getMatch(queueConfiguration.getAddress().toString());

if (as.isAutoCreateAddresses() && server.getAddressInfo(queueConfiguration.getAddress()) == null) {
   securityCheck(queueConfiguration.getAddress(), queueConfiguration.getName(), CheckType.CREATE_ADDRESS, this);
}

If the address existed but did not support the routing type being requested, no permission check ran, and the routing type was added to the address as a side effect of creating the queue. A user with createDurableQueue or createNonDurableQueue but without createAddress could therefore convert an ANYCAST-only address into one that also supports MULTICAST, or the reverse, changing the delivery semantics of a destination the permission model was intended to protect.

The path is reachable over any protocol that creates queues, including plain JMS, where subscribing to a topic on an ANYCAST-only address requests a MULTICAST queue. Exploitation requires an authenticated account that already holds queue-creation rights.

This vulnerability was introduced in 2017 with Apache ActiveMQ Artemis 2.0.0.

Mitigation

Only recent versions of Apache ActiveMQ Artemis are community-supported. The affected 2.19.x line is End-of-Life and will not receive public updates to address this issue.

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

Upgrade Apache ActiveMQ Artemis to a currently supported release that contains the fix (2.40.0 or later).
Leverage a commercial support partner like HeroDevs for post-EOL security support.

As an interim measure, review which roles hold queue-creation permissions on shared addresses. Where a broker does not auto-create addresses, a queue request naming a routing type the existing address does not support is rejected rather than silently widening the address, so setting auto-create-addresses to false for address prefixes whose routing semantics must not change reduces exposure.