CVE-2026-49157

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 incorrectly configured access control vulnerability (CVE-2026-49157) has been identified in the default web console and Jolokia configuration of Apache ActiveMQ Classic, which allows attackers with a low-privilege web console login to run broker management operations meant for administrators, such as creating and removing queues.

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
• Affected versions: <5.19.7, >=6.0.0 <6.2.6
• GitHub repository: https://github.com/apache/activemq
• Published packages: https://central.sonatype.com/artifact/org.apache.activemq/apache-activemq
• Package manager: Maven
• Fixed in:
  • OSS Apache ActiveMQ Classic 5.19.7, 6.2.6
  • NES for ActiveMQ v5.16.12

Vulnerability Info

This High-severity vulnerability is found in the org.apache.activemq:apache-activemq package in multiple versions of Apache ActiveMQ Classic. The distribution ships a Jetty configuration for the web console and the Jolokia JMX-over-HTTP endpoint at /api/jolokia. In the default jetty.xml, the constraint that accepts both the user and admin roles covers every path under /api/*, while the admin-only constraint covers only *.action requests:

<bean id="securityConstraint" class="org.eclipse.jetty.util.security.Constraint">
    <property name="name" value="BASIC" />
    <property name="roles" value="user,admin" />
    <property name="authenticate" value="true" />
</bean>
<bean id="adminSecurityConstraint" class="org.eclipse.jetty.util.security.Constraint">
    <property name="name" value="BASIC" />
    <property name="roles" value="admin" />
    <property name="authenticate" value="true" />
</bean>
<bean id="securityConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">
    <property name="constraint" ref="securityConstraint" />
    <property name="pathSpec" value="/,/api/*,*.jsp,*.html,*.js,*.css,*.png,*.gif,*.ico" />
</bean>
<bean id="adminSecurityConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">
    <property name="constraint" ref="adminSecurityConstraint" />
    <property name="pathSpec" value="*.action" />
</bean>

Any account in the user role, including the user account in the shipped jetty-realm.properties, can therefore authenticate to the Jolokia endpoint. The default Jolokia policy, jolokia-access.xml, limits the generic commands to read-style requests but then explicitly allows every attribute and every operation on all broker MBeans:

<allow>
  <!-- Allow all operations for the broker itself -->
  <mbean>
    <name>org.apache.activemq:*</name>
    <attribute>*</attribute>
    <operation>*</operation>
  </mbean>
  <!-- Allow all operations for Jolokia Config -->
  <mbean>
    <name>jolokia:type=Config</name>
    <operation>*</operation>
  </mbean>
</allow>

The policy has no deny entries for privileged broker operations and does not distinguish between web console roles. A low-privilege user can send a Jolokia exec request for org.apache.activemq:type=Broker operations such as addQueue, removeQueue, addTopic or removeTopic, and for destination operations that purge, move or send messages. That account gains the same broker management capability as an administrator, which affects the confidentiality, integrity and availability of the messages and destinations the broker holds.

‍

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

• Leon Johnson (finder)