Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2022-41678 is a high-severity Improper Authentication (CWE-287) vulnerability in Apache Activemq. Its CVSS base score is 8.8 (High).
Operationally, ranked in the top 0.3% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-6 (Least Privilege) and CM-7 (Least Functionality) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2022-41678 affects the Jolokia HTTP endpoint exposed by Apache ActiveMQ when Jetty routes requests to org.jolokia.http.AgentServlet. An authenticated user can supply a crafted JSON payload to HttpRequestHandler.handlePostRequest and executeRequest, which reaches ExecHandler.doHandleRequest via reflection and permits invocation of arbitrary MBean operations, including unrestricted deserialization through jdk.management.jfr.FlightRecorderMXBeanImpl on Java 11 and later.
An authenticated attacker can therefore chain calls such as newRecording, setConfiguration (embedding a webshell payload), startRecording, and copyTo to write an executable .jsp file to disk, resulting in remote code execution with the privileges of the ActiveMQ process.
Advisories from the Apache ActiveMQ project state that the default distribution now ships with a more restrictive Jolokia access policy; users are advised to upgrade to ActiveMQ 5.16.6, 5.17.4, 5.18.0 or 6.0.0, or to disable Jolokia or further restrict its allowed actions. The vulnerability carries a CVSS 3.1 score of 8.8 and an EPSS score that has remained near 0.93 since disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-2884
Vulnerability Data
Once an user is authenticated on Jolokia, he can potentially trigger arbitrary code execution. In details, in ActiveMQ configurations, jetty allows org.jolokia.http.AgentServlet to handler request to /api/jolokia org.jolokia.http.HttpRequestHandler#handlePostRequest is able to create JmxRequest through JSONObject. And calls to org.jolokia.http.HttpRequestHandler#executeRequest. Into…
more
deeper calling stacks, org.jolokia.handler.ExecHandler#doHandleRequest can be invoked through refection. This could lead to RCE through via various mbeans. One example is unrestricted deserialization in jdk.management.jfr.FlightRecorderMXBeanImpl which exists on Java version above 11. 1 Call newRecording. 2 Call setConfiguration. And a webshell data hides in it. 3 Call startRecording. 4 Call copyTo method. The webshell will be written to a .jsp file. The mitigation is to restrict (by default) the actions authorized on Jolokia, or disable Jolokia. A more restrictive Jolokia configuration has been defined in default ActiveMQ distribution. We encourage users to upgrade to ActiveMQ distributions version including updated Jolokia configuration: 5.16.6, 5.17.4, 5.18.0, 6.0.0.
- CWE(s)
Related Threats
Likely ATT&CK TechniquesAI
Techniques this vulnerability likely enables, inferred from its description, weakness type, and attributed-actor tradecraft. Confidence is per-technique.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly enforces the restrictive Jolokia action allow-list (or disable) that blocks invocation of dangerous MBeans such as FlightRecorderMXBeanImpl.
Requires disabling or removing the unnecessary Jolokia servlet/AgentServlet endpoint that the CVE exploits for RCE.
Enforces the access decision to deny unauthorized ExecHandler operations once the restrictive policy is defined.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
PR.AA-03 directly enforces authentication mechanisms that eliminate most improper-authentication defects, yet CWE-287 spans additional vectors (missing checks, flawed protocols, session handling) that one control does not fully close.
PR.AA-04 directly enables verification of identity assertions (mostly preventing CWE-287 in that scope) yet leaves many other authentication failure modes unaddressed (only partial prevention overall).
PR.AA-01 supplies and governs credentials/tokens that authentication relies on, removing some weak-credential cases, yet leaves verification logic, missing checks, and protocol flaws untouched.
PR.AA-02 ensures valid enrollment and unique credential binding, which reduces some improper-auth risks at issuance time but leaves runtime claim verification untouched, so each direction only partially addresses the other.
PR.PS-01 can enforce auth-related settings via hardened baselines and default reviews, blocking some config-based instances of CWE-287, yet leaves code-level auth flaws untouched so neither direction reaches mostly.
Patching/maintenance can remediate some known auth vulnerabilities after deployment (partial forward) but does not address the design or implementation of authentication logic itself (none reverse).
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Requiring authentication methods whose strength matches the sensitivity of the data and mandating multi-factor authentication directly blocks attempts to access resources without proving identity.
Verifying user identity before issuing replacement credentials and forcing changes after compromise reduces the likelihood that authentication bypass can be achieved through stolen or weak credentials.
Mandating segregated approval and oversight for non-human identities reduces the chance that weak or orphaned credentials can be exploited for unauthorized authentication.
Requiring authentication mechanisms and technical parameters for secure connections ensures that network services verify user identity before granting access, preventing exploitation of missing or weak authentication.
Security requirements specified early and verified through testing drive the consistent implementation of authentication mechanisms, decreasing the likelihood that authentication steps are omitted or incorrectly applied.
Defining the required level of trust in entity identity and the authentication mechanisms to achieve it ensures that authentication is explicitly addressed rather than omitted.