CVE-2026-108946: Apache ActiveMQ, ActiveMQ Broker: The broker does not verify user provided connection id matches connection
Improper input validation vulnerability in Apache ActiveMQ, Apache ActiveMQ KahaDB.
The ActiveMQ broker resolves connection, session and consumer state from ids that are user provided and in some scenarios does not validate that they ids are bound to that user. This allows an authenticated client to spoof another user's ids. This allows:
an authenticated client consumes from another connection's temporary queue/topic by putting the victim's connection id in its own ConsumerId, bypassing the broker-side ownership check. a duplicate ConsumerId registration is only logged, after which the attacker's RemoveInfo or disconnect tears down the victim's live subscription a forged MessageAck for the victim's ConsumerId permanently deletes an in-flight, unacknowledged message.
This issue affects Apache ActiveMQ: from 6.0.0 before 6.3.3, before 5.19.12; Apache ActiveMQ KahaDB: from 6.0.0 before 6.3.3, before 5.19.12.
Users are recommended to upgrade to version 6.4.0, 6.3.3, or 5.19.12, which fixes the issue.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache ActiveMQto a version that resolves this vulnerability.Fixed in 6.4.0 - Upgrade
Upgrade
Apache ActiveMQto a version that resolves this vulnerability.Fixed in 6.3.3 - Upgrade
Upgrade
Apache ActiveMQto a version that resolves this vulnerability.Fixed in 5.19.12 - Upgrade
Upgrade
Apache ActiveMQ KahaDBto a version that resolves this vulnerability.Fixed in 6.4.0 - Upgrade
Upgrade
Apache ActiveMQ KahaDBto a version that resolves this vulnerability.Fixed in 6.3.3 - Upgrade
Upgrade
Apache ActiveMQ KahaDBto a version that resolves this vulnerability.Fixed in 5.19.12
Event History
Frequently Asked Questions
Which deployments need remediation?
Apache ActiveMQ and Apache ActiveMQ KahaDB versions from 6.0.0 before 6.3.3, and versions before 5.19.12, are affected. The recommended fixed releases are 6.4.0, 6.3.3, and 5.19.12.
Does an attacker need broker access to exploit this issue?
Yes. Exploitation requires an authenticated client that can provide forged connection, session, consumer, or acknowledgement identifiers. Authentication alone does not prevent the attacker from spoofing identifiers associated with another user in the affected scenarios.
What could an authenticated malicious client do?
It may consume from another connection's temporary queue or topic, tear down a victim's live subscription through a forged removal or disconnect, or permanently delete an in-flight unacknowledged message using a forged acknowledgement.