Apache ActiveMQ Artemis EUVD-2026-75247

Exploitation requires three concurrent conditions: (1) the attacker must hold a valid authenticated session on the Artemis broker - anonymous or unauthenticated connections cannot trigger this path; (2) that account must be granted the MANAGE permission specifically, which controls access to management-via-messaging operations and is a privileged ACL entry distinct from standard SEND/CONSUME rights; (3) management-via-messaging must be enabled on the broker (it is the default, but can be disabled). What limits exploitation: the MANAGE permission gate is the primary barrier - deployments that follow least-privilege messaging ACLs and do not expose MANAGE to untrusted clients are not at meaningful risk. The vulnerability does not affect confidentiality or integrity; impact is limited to availability (thread starvation / DoS).

Real-world risk is moderate. The attack is authenticated and requires the MANAGE permission, a privileged role not typically granted to general messaging clients, which substantially reduces the exploitable population. The impact is availability-only: thread pinning causing denial of service, with no confidentiality or integrity compromise described. The CVSS vector is absent from the input, and no EPSS score or KEV entry is available, so quantitative exploitation probability cannot be assessed directly. That said, organizations running broker deployments where multiple internal teams or services share MANAGE credentials - even a mid-sized messaging platform supporting dozens of application teams - should treat this as a priority patch given how straightforward a DoS via crafted deserialization payloads tends to be once the permission boundary is cleared. No public exploit code or proof-of-concept has been identified. The 'important' severity rating from the Apache Security Team (rather than 'critical') aligns with the authenticated-only exploitation requirement.

An attacker who has obtained (or legitimately holds) an authenticated Artemis account with MANAGE permission connects to the broker and sends a management-via-messaging request with crafted method parameters - for example, a serialized object containing a deeply nested hash-collision structure. The broker deserializes the parameter as part of dispatch processing, triggering O(n²) or worse CPU work; repeating this across the thread pool causes thread exhaustion and renders the broker unresponsive to legitimate clients. No public proof-of-concept is available at time of analysis.