Apache ActiveMQ CVE-2026-108946

Requires an attacker who is an already-authenticated client on the ActiveMQ broker (the advisory explicitly scopes the actor as 'an authenticated client'), and a deployment where multiple distinct users/tenants share the same broker so that impersonating another connection has value. The concrete trigger is supplying a victim's connection id within the attacker's own ConsumerId (for temporary queue/topic consumption and for subscription teardown via duplicate-ConsumerId registration plus RemoveInfo/disconnect) or within a forged MessageAck (to delete an in-flight unacknowledged message); the broker fails to validate that these user-provided ids are bound to the requesting user. Limiting factors: the attacker must hold valid broker credentials and must know or determine the victim's connection/consumer id, and the temporary-queue consumption and message-deletion impacts depend on the victim actively holding such connections/subscriptions. Affects Apache ActiveMQ 6.0.0 before 6.3.3 and all releases before 5.19.12 (and the same ranges of the KahaDB component); upgrading to 6.4.0, 6.3.3, or 5.19.12 is the stated fix.

This is a genuine but conditional multi-tenant authorization flaw in Apache ActiveMQ, not a high-CVSS-but-low-risk artifact - though notably NO CVSS vector or score is published in the supplied data (NVD shows N/A), so quantitative severity signals are absent. The vuln.today decision label is 'awaiting_data', and there is no EPSS probability, no CISA KEV listing, and no PoC or exploit reference in the input - exploitation status is therefore 'no public exploit identified at time of analysis'. Apache itself rates it 'important'. The core risk driver is that the broker resolves connection/session/consumer state from user-supplied ids without confirming those ids belong to the requesting user, letting one authenticated client impersonate another's ids. The description explicitly frames the actor as 'an authenticated client', which bounds real-world risk: an attacker must already be a valid, authenticated principal on the broker, so this is a privilege/tenant-isolation break rather than an unauthenticated remote takeover. Impact is meaningful (reading a victim's temporary-queue messages, tearing down a victim's live subscription, and permanently deleting an in-flight unacknowledged message) but does not include code execution. Because no CVSS vector is provided in the input, the authentication requirement cannot be formally confirmed from a PR metric - it is stated here only because the advisory text explicitly says 'authenticated client'. Priority should track the absence of exploitation signals: patch on a normal-but-prompt cadence rather than as an emergency, since the Decision label is not act_now/emergency.

On a shared ActiveMQ broker hosting multiple authenticated tenants, a low-privileged authenticated client submits protocol commands carrying another user's connection id inside its own ConsumerId, bypassing the broker's ownership check to consume messages from the victim's temporary queue/topic. The same impersonation lets the attacker send a RemoveInfo/disconnect that tears down the victim's live subscription, or forge a MessageAck for the victim's ConsumerId to permanently delete an in-flight unacknowledged message. No public exploit or PoC is referenced in the available data, and attack complexity is low once the attacker is authenticated and knows the victim's ids.