Apache ActiveMQ Flaws Allow Security Header Injection and Jolokia Permission Abuse

Apache has fixed two security issues in Apache ActiveMQ that affect the web console and management interfaces, including a header injection flaw in MessageServlet and an incorrect default permissions issue in Jolokia access controls.

The first flaw, tracked as CVE-2026-42253, affects Apache ActiveMQ and Apache ActiveMQ Web versions before 5.19.7 and versions from 6.0.0 before 6.2.6. It allows JMS message properties to be copied into HTTP response headers without validation.

The second issue, CVE-2026-49157, affects Apache ActiveMQ versions before 5.19.7 and versions from 6.0.0 before 6.2.6. It allows authenticated low-privilege web users to access Jolokia broker-management operations that should be limited to administrators.

What changed in Apache ActiveMQ 5.19.7 and 6.2.6

Apache recommends upgrading to ActiveMQ 5.19.7 or 6.2.6 to address the latest security problems. The ActiveMQ 6.2.6 release includes several hardening changes, including disabling MessageServlet by default and improving default configuration for the broker, web console, and Jolokia.

The fixes matter because ActiveMQ often sits inside enterprise messaging, microservices, and integration environments. If administrators expose the web console or management endpoints too widely, a web-layer bug can become a practical route to broker manipulation or browser-side attacks.

The project’s ActiveMQ Classic security advisories page lists security problems fixed in released 5.x and 6.x versions, and administrators should review it alongside their deployed version line.

Issue	Affected component	Affected versions	Fixed versions	Severity
CVE-2026-42253	Apache ActiveMQ and Apache ActiveMQ Web	Before 5.19.7, and 6.0.0 through 6.2.5	5.19.7 and 6.2.6	Medium, CVSS 6.1
CVE-2026-49157	Apache ActiveMQ	Before 5.19.7, and 6.0.0 through 6.2.5	5.19.7 and 6.2.6	High, CVSS 8.8

How the MessageServlet header injection flaw works

CVE-2026-42253 comes from the MessageServlet in the ActiveMQ web console API. The vulnerable behavior copies every JMS message property into an HTTP response header without proper validation.

That design can allow an attacker to overwrite or inject HTTP response headers by setting them on JMS messages returned by the servlet. HTTP headers can influence browser behavior, caching, content handling, framing rules, and security policy enforcement.

The NVD entry for CVE-2026-42253 classifies the issue as cross-site scripting through improper neutralization of input during web page generation. It also notes that MessageServlet has been deprecated and disabled by default in the fixed releases.

Why malicious response headers can be risky

HTTP response headers are not just metadata. Browsers use them to apply security controls such as Content Security Policy, X-Frame-Options, Strict-Transport-Security, and content type handling.

If an attacker can inject or manipulate those headers, they may weaken security protections or create conditions for browser-side attacks. The practical impact depends on the ActiveMQ deployment, whether the web console is exposed, and how users interact with returned message content.

In a poorly restricted deployment, the flaw could support response manipulation, cross-site scripting, clickjacking risk, or misleading browser behavior. It becomes more serious when the ActiveMQ web console is reachable by untrusted users or integrated into internal workflows where users open broker-managed message views.

The Jolokia flaw affects low-privilege web users

CVE-2026-49157 involves incorrect default permissions for Jolokia, the JMX-over-HTTP bridge exposed through the ActiveMQ web console. The flaw allowed authenticated low-privilege web-login accounts to access broker-management operations intended for administrators.

The NVD entry for CVE-2026-49157 says affected users could run operations such as addQueue and removeQueue. That creates a risk of unauthorized broker changes in multi-user environments.

This issue requires authentication, but it still matters. Many organizations create limited web console accounts for monitoring, support, or operations. Those accounts should not have the ability to create or delete broker resources.

Security area	Risk	Why administrators should care
MessageServlet	HTTP response header injection	Can weaken browser-side protections or support response manipulation
Web console	Exposure to untrusted users	Increases the chance that web-layer flaws can be reached and abused
Jolokia	Low-privilege users accessing admin operations	Can allow unauthorized queue creation or deletion
Default permissions	Overly broad access after deployment	Can leave sensitive management functions available to the wrong users

Why web console exposure increases risk

ActiveMQ’s web console and management interfaces are useful for administrators, but they should not be treated like ordinary public web apps. They expose operational controls for messaging infrastructure.

When exposed broadly, the web console can become a target for attackers looking for vulnerable versions, weak credentials, permissive roles, or management endpoints such as Jolokia. Restricting access to trusted administrators and internal networks reduces the attack surface sharply.

The broader Apache ActiveMQ security advisories page encourages private reporting of security issues and links users to component-specific advisories. Administrators should monitor those updates because ActiveMQ has received multiple security fixes in recent releases.

Recommended mitigation steps

The main fix is to upgrade to Apache ActiveMQ 5.19.7 or 6.2.6. Administrators should prioritize internet-facing or broadly accessible deployments, especially systems where the web console or Jolokia endpoint is enabled.

The 6.2.6 release notes mention security enforcements that disable MessageServlet by default, harden broker configuration, and strengthen web console and Jolokia defaults. Those changes reduce exposure beyond the two individual CVEs.

Teams that cannot upgrade immediately should disable MessageServlet, restrict the web console, limit Jolokia access, and verify that non-admin users cannot run broker-management operations.

• Upgrade Apache ActiveMQ to 5.19.7 or 6.2.6.
• Disable MessageServlet if it remains available in a custom deployment.
• Restrict the ActiveMQ web console to trusted administrators and trusted networks.
• Review Jolokia authorization settings and remove management access from low-privilege users.
• Block public internet access to the web console and management APIs.
• Audit users, roles, queues, topics, and recent broker-management changes.
• Check reverse proxy and WAF logs for unusual requests to ActiveMQ web endpoints.

What administrators should check after patching

After upgrading, administrators should confirm the running version and verify that the web console behaves as expected. They should also check whether any custom configuration re-enabled deprecated components or loosened default access controls.

Jolokia permissions need special attention. If a low-privilege account can still create or remove queues, the deployment may carry forward a risky custom configuration even after the software update.

Administrators should also review message queues for suspicious test messages, unexpected message properties, and unusual response behavior in the web console. These checks can help identify whether someone attempted to probe the MessageServlet flaw before the patch.

How to reduce future ActiveMQ management risks

ActiveMQ deployments should follow the same security model as other sensitive infrastructure components. Management interfaces should stay internal, authenticated, logged, and limited by role.

Organizations should also track component updates closely. ActiveMQ has had several security-relevant changes in 2026, and the Classic security advisory list gives administrators a central place to review fixed issues by release line.

The separate ActiveMQ security page also provides reporting guidance and points users to advisories for different project components. Operations teams should include those pages in routine dependency and vulnerability review workflows.

Hardening area	Action	Expected benefit
Access control	Use separate admin and monitoring roles	Limits what low-privilege accounts can do
Network exposure	Keep web console and Jolokia behind trusted access paths	Reduces remote attack opportunities
Patch management	Track supported 5.19.x and 6.2.x releases	Ensures security hardening reaches production quickly
Logging	Audit broker-management operations	Helps detect unauthorized queue and topic changes
Configuration review	Check for deprecated components and custom overrides	Prevents old attack surfaces from returning after updates

Bottom line for ActiveMQ users

The latest ActiveMQ fixes show why management interfaces need tight controls. CVE-2026-42253 affects how message properties can reach HTTP response headers, while CVE-2026-49157 affects who can perform sensitive broker-management actions through Jolokia.

Neither issue should be ignored, especially in deployments where the web console is reachable beyond a small group of administrators. The safest response is to upgrade, restrict management access, and review permissions.

Apache ActiveMQ 5.19.7 and 6.2.6 provide the recommended fixes. Administrators should apply them quickly and verify that web console, Jolokia, and MessageServlet exposure match current security policy.

FAQ