Remote Code Execution via Log4J MBeans: Case Study of Apache ActiveMQ (CVE-2022-41678)

Abstract

Java Management Extensions (JMX) are indispensable for managing and administrating Java software solutions, yet when exposed through HTTP bridges such as Jolokia they can radically enlarge an application’s attack surface. This paper presents the first in-depth analysis of CVE-2022-41678, a vulnerability discovered by the authors in Apache ActiveMQ that combines Jolokia’s remote JMX access with Log4J2 management beans to achieve full remote code execution. Using a default installation testbed, we enumerate the Log4J MBeans surfaced by Jolokia, demonstrate arbitrary file read, file write, and server-side request–forgery primitives, and finally to leverage the file write capabilities to obtain a shell, all via authenticated HTTP(S) requests only. The end-to-end exploit chain requires no deserialization gadgets and is unaffected by prior Log4Shell mitigations. We have also automated the entire exploit process via proof-of-concept scripts on a stock ActiveMQ 5.17.1 instance. We discuss the broader security implications for any software exposing JMX-managed or Jolokia-managed Log4J contexts, provide concrete hardening guidelines, and outline design directions for safer remote-management stacks. The findings underscore that even “benign” management beans can become critical when surfaced through ubiquitous HTTP management gateways.

1. Introduction

In modern software architectures, Java-based middleware solutions frequently rely on standardized components and frameworks to handle common tasks such as logging, configuration management, and remote administration. Two widely adopted technologies within these Java ecosystems are the Java Management Extensions (JMX) and the Jolokia HTTP-JMX bridge [1,2]. While JMX provides a flexible and standardized method for managing and monitoring Java applications, Jolokia adds the ability to expose these management interfaces over HTTP, greatly simplifying remote administration tasks [3]. This combination, though advantageous from a management perspective, significantly broadens the potential attack surface of applications if improperly secured.

Securing modern digital ecosystems requires a comprehensive, defense-in-depth strategy, with robust protections applied across all layers of the technology stack. This includes safeguarding the physical data transmission layer within critical infrastructure like data centers, where novel chaotic encryption schemes are being developed to detect and prevent optical intrusions [4]. Concurrently, a significant body of research focuses on creating specialized cryptographic techniques to protect sensitive data types. For instance, advanced schemes are being designed to address the unique privacy and security challenges of digital images, often by combining nonlinear dynamics, compression, and chaos-driven permutation to protect against data leakage [5,6]. Complementary to these data-centric approaches is the critical need to secure the application middleware itself, as vulnerabilities in these widely-deployed components can undermine other security controls and provide a direct path to system compromise [7].

Log4J, an open-source logging framework maintained by the Apache Software Foundation, is another critical component extensively employed in Java-based software, particularly for its flexibility in handling logging configurations and outputs [8,9]. Given its ubiquity, vulnerabilities affecting Log4J have historically had widespread and severe security impacts, exemplified by the notorious CVE-2021-44228 vulnerability, known as “Log4Shell” [10,11]. Despite broad awareness and remediation efforts triggered by such events, recent disclosures indicate that Log4J-related vulnerabilities continue to emerge, especially when integrated with complex management layers such as JMX and Jolokia.

This article specifically investigates a vulnerability designated as CVE-2022-41678, identified by one of the authors during this research of the Apache ActiveMQ message broker, a widely utilized Java-based middleware solution [12]. Apache ActiveMQ is extensively deployed in enterprise environments for reliable message handling across distributed applications, frequently accompanied by robust remote management and logging infrastructure [13]. Despite the broad adoption and critical roles it fulfills, our research indicates that Apache ActiveMQ’s integration of Jolokia and Log4J management beans (MBeans) inadvertently exposes dangerous features allowing arbitrary file manipulation (read and write), server-side request forgery (SSRF), and, ultimately, full remote code execution (RCE).

While the security risks associated with JMX have been documented, prior research has largely concentrated on specific attack vectors. These include deserialization attacks targeting the underlying RMI service, or the abuse of powerful default MBeans like javax.management.loading.MLet to load arbitrary code from a remote URL. Other analyses have focused on vulnerabilities within HTTP-JMX bridges themselves, such as XML External Entity (XXE) vulnerabilities. These established attack patterns often rely on prerequisites such as the presence of a specific deserialization “gadget” in the application’s classpath or the ability for the target server to initiate outbound network connections.

A significant gap in the literature, however, pertains to exploit chains that leverage the functionality of seemingly benign management beans, such as those used for application logging, to achieve remote code execution without these classic dependencies. The full implications of exposing these non-traditional MBeans via ubiquitous HTTP gateways like Jolokia remain underexplored. This paper addresses this gap by presenting the first in-depth analysis of CVE-2022-41678. We demonstrate a novel exploit chain that abuses Log4J2’s own configuration MBeans to gain arbitrary file-write capabilities and, ultimately, remote code execution, requiring only authenticated HTTP access.

1.1. Research Objectives

Our motivation is to rigorously document, demonstrate, and articulate the precise exploitation methods of CVE-2022-41678, thus informing practitioners and researchers about previously unknown risks associated with JMX-Jolokia-Log4J interactions. While the vulnerability itself has been reported to Apache and mitigations were proposed by the maintainers [14], explicit technical documentation suitable for the scientific community has remained limited. This lack of detailed scholarly examination potentially hampers the industry’s broader understanding and response to similar emerging vulnerabilities.

CVE-2022-41678 arises from an improper exposure of certain Log4J MBeans via Jolokia’s web-based management interface in Apache ActiveMQ. Under certain default or commonly used configurations, ActiveMQ exposes powerful Log4J management interfaces that attackers can remotely invoke through HTTP requests. Using these interfaces, malicious actors can remotely modify logging configurations at runtime, enabling them to read arbitrary files to exfiltrate sensitive information and, more importantly, to write arbitrary files facilitating malicious code injection onto the server’s filesystem.

This vulnerability differs notably from previous well-known Log4J-related incidents, such as Log4Shell, because it does not involve JNDI lookups or traditional deserialization vulnerabilities. Instead, it relies purely on remote exploitation of legitimate yet improperly secured Log4J MBeans exposed via Jolokia.

This manuscript contributes to the scientific literature by offering the first comprehensive technical analysis and reproducible demonstration of the CVE-2022-41678 vulnerability. We have documented the conditions necessary for successful exploitation, clearly illustrating each step and presenting relevant technical considerations. Additionally, we provide a detailed exploration of the interaction among Java Management Extensions (JMX), Jolokia interfaces, and Log4J management beans, explaining how these elements together facilitated the vulnerability. The manuscript includes structured empirical demonstrations, using practical scenarios and explicitly crafted scripts to showcase exactly how attackers can achieve remote code execution in vulnerable Apache ActiveMQ installations. Finally, we present clear recommendations and practical guidelines designed to assist administrators and developers in implementing both immediate and long-term mitigations. Our overarching goal is not only to document and disseminate detailed knowledge about this specific vulnerability but also to draw broader attention to potential risks inherent in complex management infrastructures utilizing JMX, and especially in scenarios where these interfaces are exposed over HTTP-based administration interfaces.

1.2. Statement of Contributions

The primary scientific contributions of this paper are therefore as follows: Firstly, it provides the first in-depth, scholarly analysis of CVE-2022-41678, a vulnerability originally discovered by the authors, filling a critical gap in the existing literature.

Secondly, it identifies and systematically demonstrates a novel exploit chain that abuses legitimate, “benign” Log4J management beans, a mechanism distinct from classic Log4Shell-style JNDI lookups or traditional JMX deserialization attacks.

Thirdly, it defines and demonstrates three separate exploitation primitives (arbitrary file read, SSRF, and arbitrary file write) that arise from the same root cause, providing a comprehensive threat model for this class of vulnerability. Fourthly, it introduces a publicly available proof-of-concept tool, Log4Jolokia, ensuring the scientific reproducibility of the findings and providing a valuable resource for researchers and practitioners.

Last but not least, it generalizes the findings beyond a single product, presenting a case study on an architectural anti-pattern where exposing seemingly safe management functions over HTTP gateways creates emergent, high-severity risks in the broader Java ecosystem.

2. Materials and Methods

2.1. State of the Art

Java Management Extensions (JMX) provide a standardized and flexible mechanism for managing and monitoring Java-based applications [1]. Through the JMX framework, developers can expose management interfaces known as Managed Beans (MBeans) to enable remote configuration, diagnostics, and runtime management capabilities. Jolokia further extends the JMX paradigm by facilitating remote access to these MBeans via standard HTTP requests, significantly simplifying remote administration tasks but also increasing potential security risks if not properly secured [2,3].

Previous studies and disclosures have documented vulnerabilities involving the improper exposure of JMX interfaces and associated remote exploitation vectors [7,8]. Most prominently, the Log4J logging framework attracted global attention following the disclosure of CVE-2021-44228, known colloquially as “Log4Shell” [9,10]. This critical vulnerability permitted attackers to execute arbitrary code via malicious pattern strigs that leveraged Log4J’s JNDI lookup mechanism, triggering widespread security incidents and prompting extensive analysis within the security community [10]. However, subsequent research efforts have primarily focused on issues arising specifically from JNDI lookups, deserialization attacks, and direct network interactions, leaving a notable gap regarding detailed analysis of vulnerabilities emerging from the integration of JMX management interfaces, and the methods in which attackers can leverage legitimate Log4J features in order to obtain malicious results.

To explicitly delineate the scientific originality of this vulnerability,

Table 1. Comparison of CVE-2022-41678 with Other Java-Based Remote Exploitation Vectors.

Attack Vector	Core Mechanism	Common Prerequisites	Key Distinction of CVE-2022-41678
Log4Shell (CVE-2021-44228)	Malicious JNDI lookup triggered by attacker-controlled data being logged.	Outbound network access from the server; vulnerable Log4J version.	Independent of JNDI lookups; exploits the management plane (MBeans) rather than the data plane (log messages).
JMX RMI Deserialization	Unsafe Java deserialization of objects sent over the JMX RMI protocol.	Exposed JMX RMI connector; presence of a “gadget” in the application classpath.	Operates over HTTP, not RMI; requires no deserialization gadget; abuses application logic instead of object serialization flaws.
This Work (CVE-2022-41678)	Chaining legitimate Log4J management objects (setConfigText, getConfigText, ConfigLocationUri)	Exposed Mbeans via HTTP-JMX bridge (Jolokia).	Exposed Jolokia HTTP endpoint; vulnerable software configuration; valid (often default) credentials. The exploit arises from the insecure composition of trusted, legitimate components, not from a traditional code flaw in a single component.

provides a comparative analysis that contrasts the CVE-2022-41678 exploit chain against established Java attack vectors like Log4Shell and JMX RMI deserialization.

One of the most popular software that allows the bridging of the Java MBeans contained by the JVM to be interacted with via HTTP requests is the Jolokia software [15]. Jolokia bridges JMX to HTTP/JSON, using a typeless approach with JSON payloads instead of Java-specific serialization. Its architecture, illustrated in Figure 1, shows how a Jolokia agent within the JVM exposes MBeans to external clients.

The architecture in Figure 1 illustrates Jolokia’s critical role as an HTTP-to-JMX bridge, which translates web-based requests into direct interactions with the internal JMX MBean server. The primary security implication of this design is that it exposes powerful, low-level JVM management capabilities over HTTP, a common and widely accessible protocol. In the context of CVE-2022-41678, Jolokia is the essential component that makes the vulnerable Log4J MBeans remotely accessible. Without this HTTP bridge, an attacker would need an alternative vector to reach the MBeans, such as a directly exposed JMX RMI port, rendering this specific web-based exploit path impossible.

This manuscript was created with the purpose of addressing the gap in knowledge surrounding CVE-2022-41678 [11]. By systematically documenting, reproducing, and analyzing the CVE, we aim to provide novel insights into a previously overlooked type of remote code execution vulnerability while also aiming to expand existing knowledge by clarifying the security implications arising from complex interactions among JMX/Jolokia, and Log4J management functionalities, contributing to more robust Java-based application security practices.

2.2. Methods

To investigate and document the CVE-2022-41678 vulnerability, we designed a structured experimental approach focused on reproducing and demonstrating the vulnerability’s exploitation in a controlled environment. Our methodology involved setting up a testbed environment, conducting systematic vulnerability assessment procedures, and clearly documenting each step of exploitation using crafted scripts and commands to ensure reproducibility and technical accuracy. All tests were conducted in an isolated lab environment on non-production hosts and the disclosure to Apache followed responsible-disclosure principles.

The experimental setup began by deploying Apache ActiveMQ, which was confirmed as vulnerable to CVE-2022-41678. To ensure reproducibility and demonstrate the vulnerability’s consistency, our tests were conducted in a virtualized Linux system (Ubuntu 20.04 LTS) provisioned with 2 vCPUs, 4 GB of RAM, and 20 GB of storage, utilizing the default OpenJDK 11 runtime. Our proof-of-concept scripts were executed using Python 3.8. We focused on two key software versions: 5.17.1 served as the baseline for the initial exploit, as it was the latest stable release at the time of discovery, and version 5.17.3 was used to validate our findings against the most recent, unpatched state of the software. This specific setup, with Jolokia enabled by default, was chosen to reflect common configurations often found in real-world production environments.

For the readers that are interested in setting up their own test environment, the commands use for setting up the application can be found in Appendix A of the document.

Following deployment, we systematically explored the exposed Jolokia HTTP endpoints to enumerate accessible Log4J Managed Beans (MBeans). Our enumeration process included careful inspection of the exposed MBeans and their methods, particularly focusing on objects that allowed remote modification of Log4J configurations, such as the “setConfigText” function and “ConfigLocationUri” attribute as well as the function “getConfigText” that allowed us to read the content of the newly loaded configuration. Special attention was directed toward identifying potentially exploitable operations allowing arbitrary file reads, arbitrary file writes, and how Remote Code Execution (RCE) can be obtained via writing arbitrary JSP files.

Once potentially exploitable methods were identified, we constructed practical proof-of-concept (PoC) scenarios designed to leverage these methods for remote code execution. Each scenario was carefully scripted and automated using a Python-based exploitation framework specifically developed for this purpose, ensuring repeatable execution and reproducibility. Our scripts included commands and HTTP-based requests for setting malicious Log4J configurations, writing arbitrary files such as Java Servlet Pages (JSP files), and subsequently executing arbitrary Java code. Each step was executed with clear logging and documentation, including the detailed capturing of requests, responses, and system behavior, to allow for thorough subsequent analysis.

To validate the vulnerability’s successful exploitation and its practical implications, we carefully monitored and documented the outcomes at each step. We systematically recorded evidence of successful arbitrary file creation, modification, and loading, and conclusively demonstrated remote code execution. This rigorous approach facilitated a clear understanding of the vulnerability’s conditions, limitations, and practical impact.

Finally, responsible disclosure procedures were carefully adhered to throughout our investigation. We promptly informed Apache ActiveMQ maintainers about our findings, provided detailed vulnerability reports, and clearly documented vendor communications and remediation efforts. Our disclosure timeline and the corresponding vendor responses have been explicitly recorded and analyzed, contributing further clarity to our comprehensive evaluation of CVE-2022-41678.

3. Results

3.1. Enumeration of Exposed Log4J MBeans via Jolokia

In the initial phase of our technical investigation, we explicitly enumerated the management beans (MBeans) exposed by Apache ActiveMQ’s Jolokia HTTP endpoint. This step was crucial for understanding the scope and identifying potential exploitation vectors associated with CVE-2022-41678.

Specifically, we accessed the Jolokia API available at the default path “http://127.0.0.1:8161/api/jolokia” to enumerate and inspect available MBeans. This enumeration process revealed the presence of Log4J management objects which were accessible remotely using standard HTTP requests authenticated with default administrative credentials (“admin:admin”).

We leveraged this Jolokia functionality to identify the Log4J MBean exposed by Jolokia as follows:

The “<contextName>” parameter represents a dynamically assigned hexadecimal string identifying the Log4J context instance (for example, “2b9627bc”). This identifier can be discovered by accessing the Jolokia MBeans listing endpoint at “http://127.0.0.1:8161/api/jolokia/list”.

The enumeration process revealed that the Log4J MBean exposed several management interfaces. These included readable attributes for monitoring, such as ConfigText (which reflects the current running configuration), as well as writable attributes like ConfigLocationUri. For the purpose of exploitation, two of these exposed interfaces were identified as particularly critical due to their direct security implications:

• The method “setConfigText(java.lang.String, java.lang.String)” allowed remote users to set the Log4J runtime configuration by providing malicious XML configurations directly through HTTP requests.
• The writable attribute “ConfigLocationUri” permitted changing the source location (URI) from which Log4J loads its configuration files, allowing attackers to specify arbitrary local or remote resources.

While other management functions were available, our analysis determined that these two primitives provided the clearest and most direct path to arbitrary file read, file write, and ultimately, remote code execution.

An explicit HTTP request example demonstrating the enumeration of the Log4J MBean via Jolokia is presented below:

The response explicitly listed available MBeans, including the critical Log4J management bean used in subsequent exploitation scenarios:

This enumeration clearly demonstrated the presence and exposure of these critical Log4J management beans via Jolokia. Such interfaces enabled attacker-controlled manipulation of Log4J configurations remotely, underpinning the subsequent practical exploitation demonstrations documented in our research.

3.2. Arbitrary File Read and Server-Side Request Forgery (SSRF)

Following successful enumeration of the exposed Jolokia and Log4J interfaces, we proceeded with explicit demonstrations of arbitrary file read and Server-Side Request Forgery (SSRF) exploitations. By leveraging the Jolokia interface and specifically the writable “ConfigLocationUri” attribute exposed by the Log4J MBean, we were able to retrieve sensitive files and initiate internal HTTP requests remotely.

To demonstrate arbitrary file read vulnerability, we issued the following HTTP POST request to the Jo-lokia endpoint, changing the “ConfigLocationUri” attribute to point to a sensitive local file such as “/etc/passwd” (see Figure 2). The HTTP request used to perform this action is provided below:

Upon setting this attribute successfully, we can retrieve the result via invoking the “getConfigText” operation or by reading the value of the “ConfigText” attribute. The following HTTP request has been used to exfiltrate the file’s content remotely (see Figure 3):

The server explicitly returned the contents of “/etc/passwd” in the HTTP response, clearly demonstrating successful exploitation:

Furthermore, we tested and demonstrated the Server-Side Request Forgery (SSRF) by pointing the “ConfigLocationUri” parameter to a remote URL controlled by the attacker (“http://127.0.0.1:4444/ssrf_test”). The following HTTP request example illustrates this scenario:

On our controlled attacker server we have used the “ncat” utility to listen on port 4444, and received an incoming HTTP request initiated directly from the compromised ActiveMQ server, demonstrating the SSRF exploitation clearly (see Figure 4):

These technical demonstrations confirm unequivocally that attackers can leverage exposed Log4J management interfaces in Apache ActiveMQ via Jolokia to perform arbitrary file reads and SSRF attacks remotely, significantly exacerbating the practical severity and real-world risks associated with CVE-2022-41678.

3.3. Arbitrary File Write Exploitation

Following the demonstrations of arbitrary file read and SSRF exploitation, we further explored the capability of exploiting CVE-2022-41678 to perform arbitrary file writes via the Jolokia-exposed Log4J interfaces. Utilizing the “setConfigText(java.lang.String, java.lang.String)” method provided by the Log4J MBean, we demonstrated the ability to remotely inject a malicious Log4J XML configuration designed to write arbitrary files onto the Apache ActiveMQ filesystem.

In our proof-of-concept scenario, we crafted a specific Log4J XML configuration that instructed the Log4J to write a malicious Java Server Pages (JSP) file (“mal.jsp”) into the webserver’s accessible directory (“../webapps/admin/”).

Note: In order to create a platform agnostic payload (exploitable on both Linux and Windows) we have used forward slashes (“/”) in the respective file paths.

The JSP file embedded in the configuration contained code explicitly designed to execute a system command (id) on the server, writing its output to another file accessible to the attacker (“cmd.out”). The exact malicious Log4J configuration payload was as follows:

We delivered this configuration to the vulnerable ActiveMQ server by issuing the following HTTP POST request to the Jolokia endpoint:

The Jolokia interface explicitly responded with confirmation of successful execution (HTTP 200 OK), validating the acceptance of our malicious configuration payload (see Figure 5).

Subsequent verification clearly confirmed that the ActiveMQ server had successfully created the malicious JSP file (“mal.jsp”) on its filesystem at the specified location (“../webapps/admin/”). By accessing the URL “http://127.0.0.1:8161/admin/mal.jsp”, we triggered the embedded JSP code, effectively executing arbitrary system commands (in this scenario the Linux “id” command). The command’s output was captured in the file cmd.out, confirming successful remote command execution on the compromised ActiveMQ server (see Figure 6 and Figure 7).

These technical demonstrations conclusively confirmed the vulnerability’s exploitation capabilities through the arbitrary file writing vector. This verified attack scenario illustrates how an attacker can leverage exposed Log4J management beans via Jolokia to write arbitrary content onto the victim server, directly enabling subsequent remote code execution, thus elevating the practical severity associated with CVE-2022-41678 (see Figure 8).

3.4. Automating the Exploitation Process

As could be seen in the demonstrations presented in sections above, although we were able to successfully leverage the functionalities of Log4J over Jolokia in order to perform malicious actions such as arbitrary file read, SSRF attacks and most importantly obtaining RCE, due to the multi-step nature of the exploits we have decided to create and publish a set of Python scripts that automate this process called Log4Jolokia [17]. The scripts were made public in accordance with responsible disclosure principles, after the vendor had issued a patch and a corresponding security advisory.

In the following example we will present how the RCE attack presented above can be performed using just three simple Linux system commands (see also Figure 9).

As can be seen in the figure above, (1) first we download a known JSP payload from GitHub which we save locally in the “cmd.jsp” file, (2) the exploitation script is used to write the malicious JSP payload to the relative path “../webapps/admin/cmd.jsp”, a writeable location accessible by the Jetty webserver that allows for the execution of dynamically added JSP files. After successfully performing the exploit, we can proceed to query the server as seen in (3) and obtain the output of the executed system command, in this case the Linux “id” command (4).

4. Discussion

4.1. Security Implications

The results presented in our study underscore severe security implications for middleware systems, particularly old/unpatched versions of Apache ActiveMQ Classic, which integrate Jolokia and Log4J management interfaces without robust default security configurations. The demonstrated exploitation vectors, arbitrary file reads, SSRF, arbitrary file writing, and remote code execution, clearly indicate that improperly secured JMX MBeans, particularly when accessible remotely via HTTP, significantly elevate the security risk profile of Java applications.

Attackers exploiting CVE-2022-41678 can directly compromise critical confidentiality, integrity, and availability aspects of affected systems. Arbitrary file reads and SSRF enable attackers to exfiltrate sensitive data from the filesystem or probe internal network resources, thereby facilitating further attack stages. Ultimately, the demonstrated ease of achieving remote code execution via the arbitrary file-writing capabilities which permits persistent injection of malicious payloads directly onto server filesystems clearly amplifies the risk, allowing attackers to gain comprehensive control of the underlying server environment.

These risks are magnified in cloud-native deployments. When exploited on a cloud instance, the SSRF and RCE primitives can be used to target internal cloud metadata services, potentially leading to the theft of temporary credentials. These credentials could grant an attacker extensive access to other cloud resources within the account, such as storage buckets and databases, escalating the impact of the initial breach. Furthermore, in containerized environments like Docker or Kubernetes, achieving remote code execution on the application provides a foothold to attempt a container escape, which could compromise the underlying host node and other workloads in the cluster.

All of the above mentioned methods in which the vulnerability can be leveraged by attackers is reflected in the CVSS score [12] assigned by NVD and the Apache Foundation to CVE-2022-41678 which categorize it as a “High” risk vulnerability:

Base Score: 8.1 High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H [18]

However, based on the authors’ experience in penetration testing, the use of default or weak credentials in real-world deployments is common, thus elevating the practical severity of this vulnerability beyond what the ‘Privileges Required: Low’ metric might initially suggest. Although there are sources [14] that claim that there were at some point in time at least +7000 (out of which 3000 were considered to be vulnerable to CVE-2023-46604) unique hosts running the Apache ActiveMQ Classic software [19]. Unlike in the above case, the CVE we are researching (CVE-2022-41678) has multiple requirements such as:

• Port 8161 is reachable by the attacker
• Version of Apache ActiveMQ Classic is ≤5.17.3
• Authentication is disabled or weak/default credentials are present

Inspired by the works of A. Alabdulatif and N. N. Thilakarathne, we used Shodan to assess the potential exposure of the ActiveMQ web administration interface [16]. A query on 8 June 2025, revealed approximately 600 publicly accessible hosts (Figure 10). It is crucial to interpret this number as an upper bound of potentially exposed systems, not a direct count of vulnerable instances. A precise correlation of this data with the patch status (i.e., hosts running a vulnerable version ≤5.17.3) is not reliably feasible, as server banners captured by Shodan often do not contain the specific version information needed for such a determination. Furthermore, as previously noted, successful exploitation also depends on the presence of weak or default authentication credentials, a factor that cannot be ascertained through passive, non-intrusive scanning. Therefore, while the data indicates a significant number of publicly accessible management interfaces, the actual number of exploitable hosts is expected to be a smaller subset of this figure.

It should be noted though that these risks are not confined to ActiveMQ alone; any Java-based application leveraging Jolokia and Log4J interfaces may potentially exhibit similar vulnerabilities if configurations and security controls are insufficiently stringent. This broadens the implications of our findings, highlighting the necessity of reevaluating the security posture of management interfaces and what objects are safe to expose across the wider Java ecosystem.

4.2. Recommendations for Practitioners

In response to the security implications of CVE-2022-41678, practitioners must adopt rigorous and immediate security measures.

Firstly, administrators should perform immediate updates to the latest stable version of Apache ActiveMQ and related components, in order to address any known vulnerabilities.

Additionally, administrators should restrict external access to management HTTP endpoints, enforcing strict firewall rules and network-level segmentation to minimize exposure. Disabling or severely limiting access to the remote HTTP-based management interfaces, especially on production systems, is highly recommended.

Furthermore, administrators must ensure default credentials such as “admin:admin” are replaced immediately with robust, unique authentication credentials. Where possible, secure communication protocols such as HTTPS and strong authentication mechanisms, including certificate-based authentication or multi-factor authentication, should be enforced to mitigate unauthorized remote access.

Java developers and system integrators should limit accessible MBeans through Jolokia with only the minimal required ones for performing necessary operations. This will help reduce the attack surface by avoiding overly permissive management functionalities that could be leveraged for malicious purposes. If there is no legitimate usecase for using the Log4J MBeans in the respective environment we also recommend running Java programs with the “log4j2.disable.jmx=true” flag as this is an application independent option that only depends on the Log4J library.

In the specific case of the Apache ActiveMQ “Classic” application, the following specific measures can also be taken on case by case basis if considered relevant by the system administrators in charge of the respective systems:

-

Limiting the access of the “webapps” directory and all its contents to be read-only, thus preventing the arbitrary JSP write vectors that result in RCE; with that being said, the file read vectors are still present and exploitable

-

For granular access via Jolokia, it is also possible to manually restrict accessible MBeans by editing the “jolokia-access.xml” file.

Routine auditing and continuous monitoring of exposed management interfaces and configurations, using specialized vulnerability scanners, Security Information and Event Management (SIEM) solutions, or intrusion detection systems, are strongly recommended to detect and respond rapidly to unauthorized attempts at exploitation. For example, defenders can leverage the following monitorization metrics in order to try and identify these attacks:

-

HTTP(S) monitorization can be used to detect calls to the Jolokia endpoints targeting Log4J MBeans

-

Even though the Log4J log level can be reduced to only log “fatal” events, the application still logs certain events, and the exploit cannot be considered entirely silent. As a result, application log monitoring may represent a valid indicator to alert to potential compromises via CVE-2022-41678

Implementing a zero-trust architecture offers a robust defense-in-depth strategy. This approach is designed to prevent attackers who gain an initial foothold from moving laterally within the network or escalating privileges, as it requires that all internal communications be continuously authenticated and authorized. While retrofitting such a model onto legacy applications can be a complex and costly undertaking, it is a critical architectural consideration.

By following the above points, following explicit vendor recommendations and continuously applying industry-standard hardening practices will significantly reduce the risks associated with similar vulnerabilities in the future.

4.3. Limitations and Directions for Future Research

While our study provides explicit, detailed demonstrations of CVE-2022-41678 exploitation within controlled experimental scenarios, it also has several limitations. Our investigation primarily focused on a limited subset of representative Apache ActiveMQ versions, and though similar behaviors are anticipated in other software deployments that integrate JMX and Log4J management beans (e.g., Apache James, Apache ActiveMQ Artemis, Redhat AMQ), explicit confirmation across broader software ecosystems remains necessary. Additionally, our practical exploitation scenarios were conducted within intentionally simplified and permissive test environments; real-world deployments may include additional mitigations or network complexities influencing exploitability.

Future research should address these limitations by conducting broader empirical assessments of Jolokia and Log4J vulnerabilities across diverse platforms and configurations. Such analyses could clarify exploitation feasibility and impacts across varied real-world scenarios, enhancing overall risk assessment accuracy. Further studies are recommended to develop advanced detection techniques specifically tailored for identifying malicious usage patterns against HTTP-exposed JMX interfaces. Similarly, future work could investigate the post-exploitation risks unique to cloud-native deployments, where factors like container escapes, insecure orchestration configurations, or access to cloud metadata services could dramatically alter an attacker’s impact. Additionally, while our analysis focused on the MBean interfaces that led directly to remote code execution, a comprehensive study of all exposed Log4J management functions could uncover more subtle attack vectors, such as novel information leaks or denial-of-service conditions. Finally, research focusing on improved Java application design principles and proactive hardening strategies are crucial, aiming at minimizing the inherent risks posed by exposing powerful functionalities or even functionalities that may seem at first benign when these are remotely exposed.

Future research should also move beyond incremental technical protections to propose paradigm shifts in management interface design. A promising avenue is the formal application of zero-trust principles during the initial design phase of middleware, rather than as an external control. This would involve developing architectural patterns that treat every management function as a potential microservice with its own authentication and strict authorization, preventing the insecure composition of seemingly benign features. Such work could lead to blueprints for management stacks that are secure by design.

5. Conclusions

This paper has presented a detailed technical investigation of CVE-2022-41678, a critical vulnerability that we identified in Apache ActiveMQ resulting from improperly secured Log4J MBeans exposed via the Jolokia HTTP API. Our comprehensive analysis demonstrated multiple severe exploitation vectors. Initially, we enumerated and confirmed the exposure of critical Log4J MBeans (“setConfigText”, “getConfigText”, and “ConfigLocationUri”) via Jolokia, clearly highlighting the practical attack surface available to remote attackers.

We demonstrated that attackers could leverage these exposed interfaces to conduct arbitrary file reads and server-side request forgery (SSRF), clearly exemplified by retrieving sensitive server files such as “/etc/passwd” and initiating unauthorized internal HTTP requests.

Finally, our most critical finding was the explicit demonstration of full remote code execution. By successful leveraging the arbitrary file writing capabilities via the injection of malicious Log4J configurations through Jolokia. These crafted payloads enabled attackers to place arbitrary files, including executable Java Server Pages (JSP), directly onto the server filesystem. The primary scientific contribution of this work is the rigorous characterization of a new class of vulnerability that emerges not from a traditional code flaw, but from the insecure composition and exposure of trusted, legitimate management components.