From Logging Configuration to Code Execution: A Systematization of Log4j 2 File-Write Primitives in HTTP-Exposed JMX

Abstract

Java middleware may expose Java Management Extensions (JMX) through Jolokia’s Hypertext Transfer Protocol (HTTP) bridge. In affected ActiveMQ deployments, reachable Log4j 2 configuration managed beans (MBeans) become write capabilities and, with compatible triggers, enable remote code execution (RCE). We ask: in a specified product/version state, which writes and triggers compose into RCE, and which operational guard first fails or remains unresolved? We synthesize two published case studies into an evidence-coded method. Four write and four trigger classes recover four observed chains, isolate one model-implied pairing, and reject dependency-level candidates through failed or unresolved guards. It distinguishes ActiveMQ paths from documentation-limited Apache James, WildFly, Apache Karaf, and Red Hat AMQ cases. Egress filtering and static-file ownership do not stop every observed chain. Observed (O), derived (D), and model-implied (H) labels separate findings from hypotheses. The contribution is a falsifiable, product- and version-scoped management-plane instrument, not a new attack-stage sequence.

1. Introduction

Modern Java middleware crosses several security boundaries. Apache ActiveMQ, for example, combines messaging protocols, an administrative console, an embedded web server, logging, diagnostics, and Java Management Extensions (JMX). Jolokia exposes JMX managed beans (MBeans) through Hypertext Transfer Protocol (HTTP) and JavaScript Object Notation (JSON) requests. The effective attack surface depends on which management operations are reachable and how their capabilities compose [1,2,3]. Oracle distinguishes read-only, read–write, and fine-grained JMX authorization, while Jolokia policies can restrict command types, MBeans, attributes, and operations [4,5]. These composite management surfaces therefore require explicit operation-level security analysis.

The logging subsystem is rarely analyzed as a composable security capability. Log4j 2 configuration MBeans allow operators to change appenders, layouts, file targets, and configuration sources at runtime. If an over-privileged HTTP/JMX bridge exposes those operations, configuration mutability can become an attacker-controlled file write. A compatible execution trigger can then turn the write into remote code execution (RCE). This path does not use Java Naming and Directory Interface (JNDI) lookups or deserialization gadgets. Several documented variants also require no outbound network connection [6,7].

Prior work demonstrated this risk case by case. In affected ActiveMQ Classic deployments, a Jolokia-exposed Log4j 2 route enabled file reading and server-side request forgery (SSRF). It also provided a text-write capability used to plant a JavaServer Pages (JSP) file [8]. In affected ActiveMQ Artemis deployments, related MBeans supported three chains involving configuration overwrite, web-application archive (WAR) redeployment, and Java Virtual Machine (JVM) agent loading [9]. Those studies established product-specific behavior. They did not provide a shared method for deciding which combinations remain possible in another product, version, principal, and runtime.

Research question: For a specified product, version, principal, filesystem, and runtime, which HTTP/JMX-exposed Log4j 2 file-write capabilities compose with which execution triggers into RCE, and which operational guard first fails or remains unresolved when a candidate does not compose? Answer and principal results: We develop an evidence-coded, version-scoped decision instrument that classifies writes and triggers, tests same-deployment compatibility, and records that guard. Applied to the evidence, it yields four write classes (W1–W4), four trigger classes (T1a, T1b, T2, and T3), four observed chains, and one separately labeled model-implied pairing. The cross-platform application distinguishes complete ActiveMQ paths from documentation-limited or blocked states, and the hardening analysis identifies an observed local-write/JVMTI chain that survives egress filtering and static-artifact ownership separation. These are the study’s concrete results; the four-stage sequence is established and is not claimed as novel. Section 2.5 defines the evidence boundary and compares the instrument with established attack models.

Specific contributions of this study:

• An evidence-coded assessment procedure that evaluates HTTP/JMX reachability, Log4j Core mutation, useful file writing, and execution-trigger compatibility in one versioned environment. It records the earliest failed or unresolved operational guard instead of treating component presence as exploitability (Section 2.5 and Section 3).
• A file-write capability taxonomy and an execution-trigger taxonomy. Together they explain why the source cases require different content, transport, path, lifecycle, and runtime conditions (Section 4 and Section 5).
• A compatibility analysis that separates observed chains from derived and model-implied hypotheses. It includes a case-specific account of the Artemis Double-File-Write composition and its byte-fidelity limits (Section 6).
• A stage-indexed hardening and detection analysis that shows why egress filtering and static-artifact ownership separation do not stop every observed chain (Section 6 and Section 7).
• A cross-platform application using positive, partial, negative-control, and adjacent cases. The analysis identifies distinct failed or unresolved guards in ActiveMQ, Apache James, WildFly, Apache Karaf, Red Hat AMQ, and Spring Boot/Logback environments (Section 8).

Consistent with the responsible-disclosure posture of [8,9], both underlying vulnerabilities are patched, and this article gates operational payloads behind already-public artifacts, retaining only the abstraction required for analysis and defense. Appendix A details these reproducibility boundaries and the dual-use rationale.

2. Background and Related Work

2.1. The HTTP-Exposed Management Plane

Java Management Extensions (JMX) provide a standardized model for observing and controlling Java applications through managed beans (MBeans), each exposing runtime attributes and operations [1]. JMX was designed for trusted administrative contexts and historically used Java-specific transports such as Remote Method Invocation (RMI). Jolokia changes that exposure profile by bridging JMX to HTTP and JSON requests [2,3]. This browser-accessible interface is operationally useful, but it also makes low-level JVM capabilities reachable through a common protocol. Hardened deployments restrict those operations to trusted principals, networks, and operation sets [4,5].

The security consequences of exposing administrative services over standard protocols recur throughout measurement research. Internet-wide studies find services reachable with weak authentication, absent transport protection, or permissive access control [10,11]. Surveys of attack-surface mapping and Internet measurement explain how such exposure creates opportunities for abuse [12,13]. Research on externally visible asset discovery makes the same point for management endpoints [14]. Jolokia converts an internal management abstraction into an HTTP-accessible administrative surface; the broker’s effective attack surface therefore depends on the composition of reachable operations, not on one component alone.

2.2. Log4j 2 Configuration Mutability as a Distinct Mechanism

The Log4j security narrative is dominated by Log4Shell, tracked as Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-44228. In that issue, attacker-controlled logged data triggered a JNDI lookup and remote class loading [6,7]. Measurement work documented the incident’s scale and persistent exposure [15,16]. The mechanism studied here is unrelated to JNDI. It arises from configuration mutability: Log4j management beans can replace or redirect appenders, layouts, file targets, and configuration sources at runtime [17,18]. When those beans are reachable, logging becomes a controllable file-output engine. This mechanism belongs to a broader class in which legitimate Java components compose into exploitation paths [19,20,21,22,23]. Practical risk depends on capability reachability rather than library presence alone.

Version and configuration scope. A version and configuration caveat is essential. These management beans exist only when Log4j 2 JMX support is enabled. Log4j 2 has disabled that support by default since version 2.24.0 [24]. The primitives cataloged here therefore describe the enabled management-and-configuration pipeline present in the affected releases studied in [8,9], not a property of every Log4j 2 deployment. Each capability depends on a reachable, mutation-enabled configuration surface rather than on the library’s mere presence.

2.3. The Two Empirical Source Cases

This article does not re-report the two source vulnerabilities; it treats them as empirical instances. CVE-2022-41678 is an authorization weakness in ActiveMQ Classic caused by an overly permissive Jolokia policy. The Apache advisory illustrates impact through a Java Flight Recorder MBean route [25,26]. Our prior case study documented a separate Log4j 2 MBean route in affected deployments [8]. It established file reading, server-side request forgery, and a text write that planted a JSP, leading to RCE over authenticated HTTP. The associated Log4Jolokia artifact and exposure analysis are public [27]. We use this route as an instance of the authorization failure, not as the only vendor-canonical CVE path [28]. CVE-2023-50780 in ActiveMQ Artemis exposed the same Log4j MBean family and supported three product-specific chains [9]. Together, the studies establish source evidence but not a reusable compatibility method.

2.4. Jolokia Exploitation, Broker Security, and the Systematization Gap

Practitioner research shows that Jolokia can compose legitimate management operations into code execution [29,30]. Messaging-broker research treats enterprise messaging as transaction-critical infrastructure and analyzes protocol and broker security [31,32,33]. The available evidence is nevertheless fragmented. A report typically documents one product, vulnerability, or technique but does not provide a reusable test for same-deployment compatibility. The gap addressed here is a narrowly scoped assessment artifact for HTTP-exposed logging management.

We separate three forms of corroboration. First, the two ActiveMQ studies provide complete source chains [8,9]. Second, public reports establish individual management or trigger capabilities, including Logback reconfiguration and DiagnosticCommand.jvmtiAgentLoad, without validating every Log4j write–trigger pairing considered here [29,30]. Third, adjacent vulnerabilities demonstrate management-plane authorization risk but use different mechanisms. CVE-2026-34197 invokes ActiveMQ broker MBeans and loads a remote Spring context; it has no local file-write stage [34,35]. CVE-2024-32114 concerns missing default console authentication constraints [36]. Accordingly, neither adjacent issue is placed inside the Log4j write taxonomy.

2.5. Relationship to Prior Work, Systematization Scope, and Method

Because this article builds on two of our prior publications, we make the reuse and inference boundaries explicit.

Reused evidence: We take the observed vulnerability facts, laboratory results, and individual vectors from the ActiveMQ Classic and Artemis case studies [8,9]. We also cite the previously released artifacts needed to locate those results [27,37,38]. No payload, exploit vector, or source-case observation is presented as a new empirical finding.

New analytical artifact: This article introduces typed write and trigger categories, a same-deployment compatibility procedure, non-colliding guard identifiers, a hardening-state analysis, and cross-platform results that identify failed or unresolved guards. It also records one bounded compatibility hypothesis, chain E, without treating it as observed. The contribution lies in the evidence-coded decision artifact and its application rather than in the four-stage order itself.

Corpus and inclusion rules: We performed a bounded qualitative synthesis, not a comprehensive survey. The corpus contains the two source cases [8,9], associated public artifacts [27,37,38], independent corroborating reports [29,30], vendor advisories, and implementation documentation. A source contributes to a complete chain only when it establishes the reachable principal and operation, the file-output capability, the execution trigger, and their common product/version context. Stage-only evidence can support one guard but cannot upgrade a complete pairing to observed status. Generic attack-surface sources provide context only.

Platform sampling: The comparison set is purposive rather than statistical. The two source products are positive cases; a downstream ActiveMQ product is a partial case; James, WildFly, and Karaf test distinct bridge or logging-backend boundaries; and Spring/Logback and CVE-2026-34197 test adjacent mechanisms. This selection evaluates whether the instrument distinguishes different guard outcomes. It does not estimate vulnerability prevalence across Java middleware. New model and platform sources were last checked on 11 August 2026.

Extraction and grouping: For each candidate we record the product and version, principal, bridge and operation, configuration input, output constraints, destination class, egress and restart requirements, trigger, Java runtime, and source. W1–W4 and T1a–T3 group capabilities that share constraints; they do not count occurrences. The hardening matrix maps each control to the earliest transition it blocks, partly disrupts, or detects.

Evidence codebook: At first use and throughout the tables, O means observed in a cited complete source case; D means derived from documented components or control logic; H means model-implied but not verified end to end; and NE means not established by the available evidence. NE is an evidence-limit status, not evidence of absence or immunity. Platform roles are written separately as positive in-scope, partial positive, negative control, or adjacent. The letter D never means “documented,” and a negative control is not a claim of immunity.

Relation to established models:

Table 1. Comparison with established attack-analysis approaches.

Approach	Established Contribution	Relationship to This Work
Cyber Kill Chain [39]	Campaign phases and defensive actions across repeated intrusion activity	Broader campaign lifecycle; this work resolves one management-plane execution event
Attack–defense trees [40]	AND/OR goal refinement, attributes, formal semantics, and explicit countermeasures	Provides established branching concepts; this work contributes versioned W/T types, guards, and provenance
MulVAL/attack graphs [41,42]	Automated logical inference from reachability, configuration, vulnerability, privilege, and contextual-risk facts	General reasoning and scoring engines; this work provides a human-auditable domain artifact that could support finer predicates
Diamond Model [43]	Adversary, infrastructure, capability, and victim relationships for intrusion-event analysis and activity threads	Event correlation and campaign analysis; this work opens one capability into internal operational transitions
MITRE ATT&CK [44]	Versioned vocabulary for observed behaviors, mitigations, and telemetry	Mapping vocabulary and detection context; not a compatibility test or competing model
Present systematization	Product- and version-scoped Log4j management-plane assessment	Types W/T capabilities, tests same-deployment compatibility, records provenance, and identifies the first failed or unresolved guard

narrows the novelty claim. Campaign stages, branching, countermeasures, graph inference, and event correlation are established. The present work operates at a different scale and offers a product-specific evidence artifact that those general approaches do not supply.

Stages and branches are therefore not our novelty claim. The distinct result is a falsifiable decision method: it can generate bounded compatibility questions and can reject component-level false positives by locating the first operational guard that fails or remains unresolved.

Attack-graph reasoning remains complementary at the broader network-risk level [41,42]. Contemporary contextual-risk systems extend attack graphs with probability-based scoring, but retain the graph or risk score as the principal unit of analysis. Our narrower instrument instead records whether a specific write and trigger compose in one product state and which operational guard first fails or remains unresolved.

Table 2. Contribution boundary: source-case evidence versus the present systematization.

Element	Classic in [8]	Artemis in [9]	New in This Article
Empirical vulnerability facts and individual exploitation vectors	Yes	Yes	— (reused, cited)
JMX/Jolokia/Log4j 2 background and released artifacts	Yes	Yes	— (reused, cited)
Guard-based compatibility procedure and earliest guard outcome	No	No	Yes (Section 3)
File-write capability taxonomy over Log4j 2 formats (W1–W4)	Single vector only	Individual vectors only	Yes, unified and scoped (Section 4)
Double-File-Write as a conditionally byte-preserving composition	No	One observed product-specific chain	Yes, bounded capability analysis (Section 4)
Execution-trigger taxonomy (T1a–T3) with agent-portability analysis	Single vector only	Single vector only	Yes, unified (Section 5)
Composability and hardening-state matrix (control × chain)	No	No	Yes (Section 6)
Model-implied candidate chain E (stated, not validated)	No	No	Yes (Section 6, Section 9 and Section 10)
Evidence-coded positive, negative-control, partial, and adjacent platform analysis	No	No	Yes (Section 7 and Section 8)

Note: — indicates that no new empirical vulnerability fact or individual exploitation vector is claimed; the source evidence is reused and cited.

summarizes the contribution boundary.

3. Guard-Based System and Threat Model

3.1. System, Principal, and Causal Scope

The initial principal is an authenticated Jolokia or broker-management user. We consider anonymous access, stolen credentials, and an over-privileged legitimate role as separate reachability cases. The principal has no operating-system shell, local file access, or privilege outside the management plane at the outset. The security boundary is crossed when management operations produce code execution with the broker service account’s filesystem, network, and runtime authority.

Figure 1 shows the causal capability spine. A complete file-mediated chain requires four capabilities in one assessed state. First, the principal must be able to access a reachable HTTP-to-JMX bridge. Second, an exposed Log4j Core configuration surface must permit the principal to invoke mutation operations. Third, a write must produce the required bytes at a suitable destination. Finally, an authorized trigger must consume the artifact. Code execution follows only when all four transitions hold in the same product, version, principal, filesystem, and runtime. A failed guard ends the scoped chain at blocked.

The sequence is causal, not a novelty claim. It forms a logical AND spine with alternative writes and triggers. This narrower view complements campaign models, attack–defense trees, ATT&CK, and attack graphs [39,40,41,43,44]. It opens one management-plane event into product-specific transitions that can be checked independently.

Figure 1. Causal capability spine. Forward arrows are monotone target-state prerequisites. A failed guard terminates the candidate as blocked; analytical backtracking is shown separately in Figure 2.

Figure 1. Causal capability spine. Forward arrows are monotone target-state prerequisites. A failed guard terminates the candidate as blocked; analytical backtracking is shown separately in Figure 2.

Figure 2. Iterative guard-based assessment procedure. Solid arrows evaluate one candidate forward. Dashed arrows select another analytical candidate after an incompatibility. The outcome records both compatibility and O/D/H/NE evidence status.

Figure 2. Iterative guard-based assessment procedure. Solid arrows evaluate one candidate forward. Dashed arrows select another analytical candidate after an incompatibility. The outcome records both compatibility and O/D/H/NE evidence status.

3.2. Operational Guards

Table 3. Operational guards and assessment outcomes.

Guard	Question	Conclusion When the Guard Fails or Remains Unresolved
G-R1	Is an HTTP-to-JMX bridge installed and reachable in the assessed state?	The scoped HTTP chain is ruled out
G-R2	Can the principal authenticate and pass bridge-level access controls?	The bridge is unavailable to that principal
G-M1	Is Log4j Core present, rather than only the Log4j application programming interface (API)?	The Core mutation route is absent
G-M2	Are Log4j Core configuration MBeans registered and exposed through the bridge?	The scoped mutation route is absent or not established
G-M3	Can the principal invoke setConfigText or write ConfigLocationUri?	The required mutation is denied or not established
G-W1	Can the selected configuration write to the required destination?	The write stage is blocked
G-W2	Do layout, charset, delimiter, exception, and overwrite semantics preserve a trigger-compatible artifact?	The produced artifact is incompatible
G-T1	Does an available trigger consume this artifact in the same environment?	No complete pairing exists
G-T2	Is that trigger reachable, authorized, and lifecycle-compatible?	The trigger is blocked
G-C	Do the selected write and trigger compose in the same version, process, filesystem, class-loader, and lifecycle?	No complete pairing is established

makes each prerequisite falsifiable. Guard identifiers use a G-prefix so they cannot be confused with write types W1–W4, trigger types T1a–T3, or evidence labels. Evidence key: O = observed; D = derived; H = model-implied; NE = not established. “Not established” means that the available source does not prove the guard; it is not proof that the capability is absent.

These guards also separate authentication from authorization. Removing anonymous access changes G-R2 for one principal class, but it does not constrain an authenticated administrator. Operation-level allow-listing can instead make G-M3 or G-T2 fail for every role that does not require those capabilities.

3.3. Iterative Assessment Procedure

Figure 2 separates target-state causality from the analyst’s search procedure. The analyst first establishes reachability and mutation authority, then chooses a write and a trigger. Compatibility testing covers paths, permissions, byte fidelity, lifecycle, authorization, and JVM or class-loader constraints.

If one trigger is incompatible, the analyst tests another trigger. If all triggers fail, the analyst revisits the write choice. If the bridge, mutation surface, writes, or triggers are exhausted, the result is blocked/not established, together with the earliest failed or unresolved guard. Dashed arrows are analytical backtracking; they do not imply that a completed target-state transition is physically reversed.

The procedure’s value is discriminative rather than tautological. Dependency or component-name evidence may nominate a product, but it does not resolve G-R1, G-M1/G-M2, operation authority, or same-environment W/T compatibility. Section 8 applies these guards to positive, partial, negative-control, and adjacent platforms.

4. File-Write Capability Taxonomy

The file-write stage is not monolithic. Configuration format, source transport, layout, charset, destination permissions, and overwrite behavior determine whether the output can satisfy a trigger.

Table 4. File-write capabilities over exposed Log4j 2 configuration MBeans. Evidence key: O = observed in a cited complete source case; D = derived; H = model-implied; NE = not established.

ID	Capability	Operation and Source	Output/Egress	Required Guards and Principal Failure Modes	Scope and Provenance
W1	Inline XML push	setConfigText(String,String) with inline Extensible Markup Language (XML)	Text-only; no egress	XML 1.x character limits; entity encoding; writable destination; trigger accepts text [45]	O: JSP write in affected Classic and broker.xml write in affected Artemis [8,9]
W2	Remote Properties pull	Write ConfigLocationUri; remote HTTP or File Transfer Protocol (FTP) configuration	Binary-capable in the observed pipeline; egress required	Remote protocol allowed; source reachable; exact layout/charset and destination semantics; operation authorized	O: WAR overwrite in the documented Artemis environment [9]
W3	Local Properties load	Write ConfigLocationUri; local file: configuration	Intermediate dependency; no independent output claim	Requires a previously written Local Properties file and authorization for the URI update	Dependency-only within observed W4; do not count as an independent chain [9]
W4	Double-File-Write composition	setConfigText, then local ConfigLocationUri	Binary-capable only when the complete pipeline preserves bytes; no egress in the source case	Staging and final paths writable; local file: loading allowed; layout, charset, delimiter, exception, append/overwrite, and artifact-tolerance guards all pass	O only in the documented Artemis environment; portability is untested [9]

classifies the capabilities extracted from the source cases [8,9]. W3 is shown because W4 depends on it; W3 is not independently established as an attacker-reachable write from the baseline state.

Format and pipeline constraints: W1 is simple to invoke, but XML 1.x excludes null bytes and most control characters [45]. It therefore supports the observed text artifacts, not arbitrary archives or agent files. A Properties configuration can express escaped characters in ASCII, but that syntax alone does not prove arbitrary-byte output. Log4j layouts produce strings that are converted to bytes under a charset, and layouts may add delimiters, newlines, or exception output. Binary fidelity is therefore a property of the complete configuration-to-output pipeline. W2 also depends on a permitted and reachable remote configuration source.

W4 scope: W4 is an observed, case-specific composition in the Artemis environment. The first mutation writes a Local Properties configuration; the second loads that file and writes the target artifact. Success is conditionally byte-preserving. It depends on layout transformations, charset, delimiters, exception rendering, append/overwrite behavior, path permissions, local file: loading, and the trigger’s artifact tolerance. Those conditions held in the documented source case [9]. Portability to another product or version requires independent verification of every guard.

In the observed Artemis environment, W4 removed W2’s outbound-connectivity dependency while preserving the required artifact bytes. This relationship is conditional and is not asserted for other products or versions. W2 may remain viable where ConfigLocationUri is authorized but setConfigText is not, or where local staging, file loading, permissions, or byte fidelity fail.

Explanatory result: The Classic chain required a text JSP, so W1 sufficed without egress [8]. The Artemis WAR and Java archive (JAR) paths required binary-compatible output, leading to W2 and W4 in the source environment [9]. The asymmetry follows from configuration and output constraints [18,46], not from broker names alone. Operational encoding code and payloads remain in the already-published artifacts; this section retains only the analytical boundaries.

5. Execution-Trigger Taxonomy

A file write is not code execution. A later event must consume the written artifact.

Table 5. Execution triggers for written artifacts. All trigger types are observed (O) in the cited source cases [8,9]. Evidence key: O = observed; D = derived; H = model-implied; NE = not established.

ID	Trigger	Mechanism/MBean Operation	Consumption Event	Restart Scope	Egress	Web Server Required	Evidenced by
T1a	Web-root script	write executable script into a web-served directory	HTTP request to the script	none	no	yes (server executes JSP)	JSP path [8]
T1b	WAR redeploy	restartEmbeddedWebServer() (broker MBean)	embedded Jetty redeploys the overwritten WAR	embedded server only	no	yes	WAR vector [9]
T2	Config-on-restart	overwrite broker.xml network-check-ping-command; optionally induce restart via forceFailover()	full application startup evaluates the command	whole JVM/application	no	no	broker.xml vector [9]
T3	JVM-agent load	DiagnosticCommand.jvmtiAgentLoad	agent attached to the running JVM immediately	none	no	no	JVM-agent path [9,37]

classifies the observed triggers by mechanism, consumption event, and operational preconditions. In T1a, the write ends when the JSP file is created; the later HTTP request is the distinct execution trigger.

Operational preconditions: T1a requires a web container that executes JSP files; it does not require a restart. T1b requires a valid replacement WAR, a monitored destination, and authorization to restart the embedded web server; it does not restart the JVM. T2 requires a full application startup before the modified configuration is consumed. Secure deployment and recovery controls are designed to prevent unauthorized artifacts from being accepted during such lifecycle events [47].

T3 and agent-artifact portability: In the documented environment, jvmtiAgentLoad is exposed by the com.sun.management:type=DiagnosticCommand MBean. It loads an agent into the running JVM without a web server, restart, or outbound connection [48]. Oracle documents the command as loading a native agent [49]. The JAR-accepting branch is a HotSpot/OpenJDK implementation detail, not a general property of the Java Virtual Machine Tool Interface (JVMTI) specification [50]. Native agents remain operating-system- and library-specific. The Artemis source case instead used a JAR-packaged agent [9,37]. That container can be operating-system-neutral, but its execution still depends on class-file compatibility, payload logic, paths, permissions, runtime implementation, and operation authorization. We therefore treat T3 as observed in the documented HotSpot/OpenJDK environment, not as universally portable.

6. Composability and Hardening-State Model

A complete file-mediated chain is a write–trigger pair whose guards hold in the same environment.

Table 6. Observed and model-implied file-write-to-execution chains. Evidence key: O = observed; D = derived; H = model-implied; NE = not established.

Chain	Write	Trigger	Description	Status
A	W1	T1a	Text configuration writes a JSP; a later HTTP request executes it	O—observed in affected Classic [8]
B	W1	T2	Text configuration modifies broker.xml; application startup consumes it	O—observed in affected Artemis [9]
C	W2	T1b	Remote Properties configuration produces a WAR; embedded-web-server restart redeploys it	O—observed in affected Artemis [9]
D	W4	T3	Local double write produces a JAR; the diagnostic command loads it	O—observed in affected Artemis [9]
E	W4	T1b	Local double write produces a WAR for redeployment	H—model-implied; not validated end to end

lists the four observed source chains and one bounded model-implied pairing.

6.1. Compatibility Status Matrix

Table 7. Status-only W × T compatibility matrix. Evidence key: O = observed; D = derived; H = model-implied; NE = not established. H cells are hypotheses, not evidence of exploitability.

Write	T1a: Web Script	T1b: WAR Redeploy	T2: Configuration on Restart	T3: JVM-Agent Load
W1 inline XML	Observed (O), A	Incompatible: text/archive	Observed (O), B	Incompatible: text/agent
W2 Remote Properties	Dominated (H) 1	Observed (O), C	Plausible (H) 2	Plausible (H) 2
W3 Local Properties	Dependency-only	Dependency-only	Dependency-only	Dependency-only
W4 double write	Dominated (H) 3	Plausible (H), E	Dominated (H) 4	Observed (O), D

Notes: ¹ Only where W1 is also authorized; otherwise reassess. ² Path, lifecycle, artifact, and operation-authority guards remain unresolved. ³ W4 entails W1 mutation in the source construction, while W1 already satisfies a text artifact. ⁴ Only in the source configuration where W1 provides the required text configuration.

asks the question generated by the taxonomies: can each write type satisfy each trigger’s artifact class? Observed (O) denotes a complete source pairing. Plausible (H) denotes compatibility in principle with unresolved same-environment guards. Dominated (H) denotes a hypothesis for which a simpler observed write suffices under the stated source baseline. Incompatible identifies an artifact-class conflict. Dependency-only is reserved for W3.

Table 7 exposes more unobserved cells than the five chains in Table 6. We identify E separately because W4 is observed in D and T1b is observed in C; their combination makes E the most immediate compatibility question. All other unobserved cells retain H status and are not counted as chains or presented as product vulnerabilities. The matrix discloses status only: it contains no payload, path construction, command sequence, or operational procedure.

6.2. Hardening-State Analysis

Table 8. Exact hardening-state outcomes by control and chain; the notes below define partial and detection-only results. Evidence key: O = observed; D = derived; H = model-implied; NE = not established.

Control (Stage Interrupted)	A (JSP)	B (Broker.xml)	C (WAR/Remote)	D (JAR/JVMTI)	E (WAR/Local)—H
Patch to fixed release (exposure)	Blocks	Blocks	Blocks	Blocks	Blocks
Disable anonymous Jolokia (authentication)	Partial 1	Partial 1	Partial 1	Partial 1	Partial 1
Restrict Jolokia to trusted networks (reachability)	Partial 2	Partial 2	Partial 2	Partial 2	Partial 2
Log4j 2 MBean allow/deny-list (mutation)	Blocks	Blocks	Blocks	Blocks	Blocks
Restrict DiagnosticCommand (trigger T3)	No effect	No effect	No effect	Blocks	No effect
Filesystem ownership separation (write target)	Partial 3	Blocks	Blocks	No effect 4	Blocks
Egress filtering (transport)	No effect	No effect	Blocks 5	No effect	No effect
Artifact integrity monitoring (write target)	Detects	Detects	Detects	Detects 6	Detects
Audit Jolokia writes/MBean ops (all stages)	Detects	Detects	Detects	Detects	Detects

Notes: ¹ Affects only the unauthenticated branch and does not constrain an authenticated principal. ² Affects only principals outside a correctly enforced trusted-network boundary. ³ Protecting the web root is target-specific. ⁴ The observed chain uses a writable staging path outside static-artifact separation. ⁵ Affects W2, not local W4. ⁶ Static-artifact monitoring may miss writable staging locations.

maps controls to the earliest transition they block, partly disrupt, or detect. Preventive outcomes are derived (D) from the mechanism, not measured across every release. Column E applies the same logic to a model-implied chain and remains H.

Defensive result: Chain D survives egress filtering and static-artifact ownership separation in the observed environment. It is stopped by removing the vulnerable exposure, denying the Log4j mutation operations, or restricting DiagnosticCommand. A network boundary also stops a principal that remains outside that boundary. Transport and static write-target controls are therefore insufficient on their own. The most robust controls remove the affected exposure or deny mutation or trigger authority at G-M3 or G-T2. Figure 3 summarizes the outcomes reported in Table 8.

Status of E: Chain E is generated by compatibility reasoning, not observation. It requires a byte-preserving W4 output at the monitored WAR destination, sufficient staging and overwrite permissions, a valid archive, compatible deployment semantics, and authorization for T1b. These conditions are necessary but may not be sufficient. E demonstrates how the method generates a bounded validation question; it does not establish another exploitable product.

7. Detection and Defensive Mapping

The guard structure also organizes detection. Payload signatures are brittle because each chain composes legitimate management operations. State-transition signals are more stable: mutation calls, artifact changes, consuming events, and correlated retrievals. Their availability remains product-specific, so the following items are a checklist rather than universal guarantees.

At the mutation stage, an unexpected setConfigText call or write to ConfigLocationUri is the decisive observable. Either operation can convert logging configuration into a file-write capability and should be treated as security-relevant.

At the write stage, changes to artifact timestamps, hashes, or ownership provide observables. Relevant locations include broker.xml, deployed WAR files, and writable temporary directories. Monitoring only static deployment artifacts misses chain D’s staging location.

At the trigger stage, relevant events include restartEmbeddedWebServer, a broker restart or forceFailover shortly after configuration mutation, and jvmtiAgentLoad. Their visibility depends on the product’s audit configuration.

At the transport stage, W2 produces an outbound HTTP or FTP retrieval correlated with runtime configuration loading. W4 uses local staging and produces no such retrieval. The absence of outbound traffic therefore does not show that no write occurred.

Every modeled chain invokes a Log4j 2 configuration-mutation operation. Complete, tamper-resistant monitoring of those operations is therefore the broadest detection anchor within this model. Such monitoring cannot distinguish exploitation from legitimate administration by itself. Correlating mutation, file, trigger, and transport observations improves specificity.

These observation points are not guarantees. Management-plane calls are not always logged by default, temporary-directory monitoring is noisy, and file-integrity telemetry requires configuration. Detection therefore complements rather than replaces the preventive controls in Section 6, and its value depends on audit completeness and timely alert handling.

The following vendor-neutral signatures follow directly from the stage observables and can be expressed as management-plane audit rules without reference to any payload:

• Any invocation through the HTTP-JMX bridge of a Log4j 2 configuration-changing operation—setConfigText, or a write to the ConfigLocationUri attribute—treated as security-relevant rather than routine;
• Any DiagnosticCommand.jvmtiAgentLoad invocation, and any restartEmbeddedWebServer() or forceFailover() call occurring within a short window after a configuration-changing operation;
• New-file or modified-file events (modification time, hash, ownership) not only on protected deployment artifacts such as broker.xml and deployed WARs but also on writable temporary directories, which the local double-write chain uses for staging;
• Outbound HTTP or FTP retrievals temporally correlated with runtime configuration loading, whose absence must not be read as evidence that no write occurred.

For teams using MITRE ATT&CK v19.2, the stages map by analogy onto current techniques [44]. Reachability resembles Exploit Public-Facing Application (T1190), or Valid Accounts when legitimate management credentials are used. T1a resembles Server Software Component: Web Shell (T1505.003). T2 resembles Event Triggered Execution (T1546) combined with Command and Scripting Interpreter (T1059). Shared Modules (T1129) is the closest analogy for T3 [51]. Process Injection and Reflective Code Loading do not match the observed procedure. The relevant data sources are management and application audit logs, file-integrity telemetry, and network traffic. Automated CVE-to-ATT&CK classification can assist large-scale triage [52], but the present mapping remains analyst-reviewed because it concerns mechanism-level stage analogies rather than classification from vulnerability text. These mappings are not evidence that every technique definition is fully satisfied.

These correspondences are analogies for triage; we do not claim that the management-plane behavior satisfies the full definition of every mapped technique.

8. Cross-Platform Guard Evaluation

Generalization is useful only when it produces testable and bounded results. We therefore ask a stronger question than whether a platform contains a familiar dependency: which earliest operational guard does component-level inference fail to resolve?

Table 9. Evidence-coded platform evaluation. Evidence key: O = observed; D = derived; H = model-implied; NE = not established.

Platform/Assessed State	Role	Earliest Guard Result	Evidence and Claim Limit
Affected ActiveMQ Classic and Artemis source cases	Positive in-scope	Complete paths A–D	O: the cited studies establish complete, versioned pairings in the Classic and Artemis broker families [8,9,53,54]
Spring Boot/Logback with exposed Jolokia actuator	Adjacent backend	Reachability and logging mutation documented; downstream mechanism differs	O/NE: published work establishes the adjacent Logback route but not a W1–W4 pairing; it uses reconfiguration and an XML external entity/JNDI path [29,55]
Red Hat AMQ Broker 7.12	Partial positive	G-R1 and logging are documented; G-M2/G-M3 remain version-specific	NE: Jolokia/hawtio management and Log4j 2 logging are documented [56,57], but exact-version mutation authority is unresolved. Susceptibility is not inherited from Artemis ancestry; earlier productized observations remain scoped to their studied releases [58]
Apache James stock documentation	Negative control	G-R1 is not established for the scoped HTTP bridge	NE: James documents a JMX endpoint and discourages remote exposure; the cited stock documentation does not document Jolokia or another HTTP-to-JMX bridge [59]. The result must be reassessed if a bridge is added
WildFly stock logging integration	Negative control	G-M1/G-M2 fail	D: the Log4j API delegates to JBoss LogManager; Log4j Core implementation and configuration APIs are explicitly unsupported in the stock integration [60]
Apache Karaf 4.4.11 documented stock state	Negative control	G-R1 is not satisfied in the documented stock state	D: Karaf documents JMX over RMI by default and installs Jolokia only as an optional feature after the HTTP feature [61]. No runtime measurement was performed
CVE-2026-34197	Adjacent operational case	No local write stage	O: authenticated Jolokia invocation of ActiveMQ broker MBeans loads a remote Spring context and reaches runtime execution [34,35]. It is outside the W × T matrix

applies vendor and project documentation to exact product states. No new exploit execution, active scanning, or mutation testing was performed.

The results are deliberately asymmetric. The source ActiveMQ cases satisfy complete paths. The cited James documentation does not establish the scoped HTTP bridge. Stock WildFly lacks the required Log4j Core integration. The documented Karaf stock state fails at the optional HTTP/Jolokia feature boundary. Red Hat AMQ satisfies documented management and logging conditions but retains version-specific mutation unknowns. A single label such as “uses Log4j” cannot express these differences.

Log4j’s current default further limits inheritance across releases: JMX support is disabled by default beginning with Log4j 2.24.0, whereas earlier versions enabled it by default [24]. Current products must therefore be evaluated in their exact packaging and startup state. The presence of log4j-api is not evidence that Log4j Core, its configuration MBeans, or mutation authority exists.

CVE-2026-34197 provides adjacent operational evidence for the authorization thesis. The affected ActiveMQ Classic releases are 5.x versions before 5.19.4 and 6.x versions from 6.0.0 through 6.2.2; Apache recommends 5.19.4 or 6.2.3 [35]. CISA added the issue to the Known Exploited Vulnerabilities (KEV) catalog on 16 April 2026, with a remediation due date of 30 April 2026 [34,62]. Its mechanism contains no local file write, so it corroborates management-operation risk without expanding the Log4j file-write taxonomy.

A safe read-only Karaf measurement would be a valuable future extension. It should record the exact image digest, Java and component versions, effective log4j2.disableJmx state, exposed MBean domains, and role-based access-control metadata. Metadata visibility can establish registration and exposure; it cannot prove mutation authorization. We report no such measurement in this study.

9. Discussion

The recurring failure is an authorization gap at the operation level. Authentication establishes who reached the management plane; it does not establish which MBean operations that principal should invoke. The observed chains compose legitimate functions: logging reconfiguration, file output, component restart, and diagnostic loading. An authenticated interface remains hazardous when one role can combine these functions without an additional operation-level policy decision.

This is a management-plane instance of established security principles. Least privilege requires the minimum authority needed for each task [63]. The confused-deputy analysis explains how a privileged component can wield ambient authority for an unintended caller [64]. Object-capability systems instead make authority explicit and narrowly scoped [65]. A bridge that authenticates once and then exposes broad logging, broker, and diagnostic functions resembles a confused-deputy configuration. Common Weakness Enumeration classifies the missing per-operation decision as missing authorization (CWE-862) [66]. NIST zero-trust guidance similarly rejects implicit trust based on network location and calls for granular application-level policy based on user, application, and service identities [67]. Runtime isolation and per-user container policies provide a complementary deployment boundary [68].

The logging subsystem is therefore a capability, not merely a utility. Runtime configuration is appropriate in a trusted administrative context. Through an over-privileged HTTP bridge, the same mutability can cross a file and execution boundary. Secure management stacks should minimize exposed MBeans, authorize mutation and trigger operations separately, separate writable configuration from executable artifacts, and restrict runtime loaders that are not required. These controls form a defense-in-depth structure consistent with multilayer security frameworks [69], although the layers here are management-plane guards rather than an Internet of Things protocol stack.

Why not simply disable JMX or Jolokia? Disabling HTTP-exposed management is the strongest option when operations permit it. Many deployments retain browser-based management, however. The guard method identifies the smallest operation-level restriction that breaks a chain in those deployments. It also shows which residual chains survive egress filtering or static write-target hardening. This decision value is more specific than a generic instruction to disable management.

The method also explains its own boundary. Chain E is a compatibility hypothesis, not a finding. CVE-2026-34197 is operationally important, but it follows a different no-write route. These examples show that the instrument can generate and reject scoped questions without turning every management-plane issue into the same taxonomy.

10. Threats to Validity

Selection validity: The complete empirical chains come from two Apache ActiveMQ-family products. The corpus is intentionally bounded and may omit other management-plane write or trigger categories. We therefore claim a structured synthesis of the cited evidence, not exhaustive coverage of JMX, Jolokia, logging frameworks, or Java middleware.

Source validity: Peer-reviewed source cases support observed chains. Vendor documentation supports advertised behavior, defaults, and version boundaries. Practitioner reports support only the capabilities they directly document. Documentation can lag packaging, and current pages may not describe historical releases. O/D/H/NE statuses and access dates make those differences visible but cannot remove them.

Construct validity: The guard procedure simplifies implementation details into discrete results. A guard marked present can still hide path, class-loader, filesystem, or policy conditions that prevent composition. Conversely, “not established” records an evidence limit and does not prove absence. The compatibility matrix is status-only; its H cells are analytical hypotheses rather than exploitability evidence.

Version and measurement validity. Log4j defaults, Jolokia policies, Java Development Kit (JDK) diagnostic commands, and product packaging change across releases. The platform table is documentation-based. No Karaf runtime enumeration or new exploit execution was performed. Each current deployment therefore requires exact-version verification before a mutation or compatibility conclusion is transferred.

External and impact validity: The analysis stops at initial code execution. It does not model persistence, privilege escalation, lateral movement, or exfiltration. Service-account privilege, network segmentation, container boundaries, and monitoring quality determine real-world impact. Hardening outcomes in Table 8 are mechanism-derived and must be tested in the target environment. Chain E remains H throughout Table 6, Table 7 and Table 8 and Section 9.

11. Conclusions

Research question and answer: This study asked which HTTP/JMX-exposed Log4j 2 file-write capabilities and execution triggers compose into RCE in one specified product/version state, and which operational guard first fails or remains unresolved. The evidence-coded procedure answers by testing bridge reachability, mutation authority, write suitability, and trigger compatibility in the same principal, filesystem, and runtime context. Specific results and contributions: It produced four write classes (W1–W4), four trigger classes (T1a, T1b, T2, and T3), four observed source chains, and one bounded model-implied pairing kept separate from findings. It distinguished complete ActiveMQ paths from documentation-limited or blocked Apache James, WildFly, Apache Karaf, and Red Hat AMQ states, and showed that the observed local-write/JVMTI chain D survives egress filtering and static-artifact ownership separation. The resulting contribution is a falsifiable, product- and version-scoped management-plane decision instrument that rejects dependency-level false positives by recording the earliest failed or unresolved guard. Robust mitigation should constrain reachability, Log4j mutation authority, or trigger authority. Typed compatibility, provenance, and guard-level discrimination—not a new attack-stage sequence—turn the product-specific cases into a reusable assessment method.