jmx2rce: Best Security CLI for Red Teams and Pentesters in 2026

What Is jmx2rce?

jmx2rce is a Go-based security CLI by hacktus that targets Apache Tomcat's unauthenticated JMX proxy and chains it into arbitrary file read or remote code execution through AccessLogValve reconfiguration and Expression Language (EL) injection. jmx2rce is one of the best Security CLI tools for red teams and pentesters who need a single static binary, cross-platform support, and a workflow with 4 operator modes: scan, read, rce, and cleanup.

The repo is intentionally narrow in scope. It focuses on one Tomcat attack path, automates the state changes needed to exploit it, and then restores the original configuration so a test window can be closed cleanly.

Quick Overview

Who Should Use jmx2rce?

Use jmx2rce when you need a repeatable Tomcat validation workflow from a terminal instead of a browser or a heavy framework. It is built for operators who care about exact request paths, MBean attribute changes, and deterministic cleanup.

• Red teams validating whether Tomcat Manager JMX proxy access is exposed without authentication and whether that exposure is exploitable beyond simple read-only access.
• Pentesters who want to prove impact with a concrete file-read or RCE chain instead of just reporting a weak endpoint.
• Security engineers auditing legacy Tomcat fleets where one misconfigured connector or valve can expose the whole instance.
• Automation-minded operators who want a CLI that can scan a target list, emit JSON, and fit into a scripted workflow.

Not ideal for:

• Public internet scanning without explicit authorization, because the tool mutates server state and can disrupt service.
• Non-Tomcat targets, since jmx2rce depends on Tomcat's JMX proxy, MBeans, and AccessLogValve behavior.
• Hands-off vulnerability management, where you only need passive detection and do not want a tool that performs write operations.

Key Features of jmx2rce

• Tomcat JMX proxy discovery — jmx2rce starts with a direct request to /manager/jmxproxy/?get=Catalina:type=Server&att=serverInfo and checks for the OK - ... response pattern that Tomcat returns when the proxy is exposed. That gives you a fast signal on whether the management surface is reachable before any write operation happens.

• Arbitrary file read chain — the read mode saves the ROOT webapp docBase, repoints it to the directory that contains the target file, reloads the context, and then requests the file as a normal HTTP resource. This is a clean Tomcat-native read primitive, not a shell, and it works because the ROOT context temporarily serves from the attacker-chosen filesystem path.

• AccessLogValve JSP injection — the rce mode writes the access log into webapps/ROOT, changes the suffix to .jsp, and uses a custom log pattern so the payload lands inside a JSP file. When Tomcat compiles that file, the EL payload is evaluated in the server process, which is why the repo shows a proof-of-concept payload like 7*7*7 and a command execution example for Tomcat 9+ with EL 3.0.

• Stateful cleanup path — the cleanup mode restores the original ROOT docBase, resets the AccessLogValve defaults, and clears connector-level changes such as relaxedQueryChars. That matters because this is not a throwaway exploit; jmx2rce is built to leave the instance in a known state after validation.

• CDN-safe triple encoding — the tool encodes %{X-Payload}i as %2525%257BX-Payload%257Di so intermediate proxies do not destroy the access log token before Tomcat sees it. This is the kind of detail that decides whether a payload survives a reverse proxy chain or gets mangled into a no-op.

• Cross-platform static binary — the repo ships as a single static Go binary with no external dependencies, and the page explicitly calls out macOS, Linux, and Windows support. That makes jmx2rce easy to drop into a lab VM, a CI runner, or a disposable red-team box without building a Python environment first.

• Bundled nuclei template — the repository includes tomcat-jmxproxy-unauth.yaml for mass detection and version extraction. That gives you a fast prefilter before you switch to the exploit chain in jmx2rce itself.

jmx2rce vs Alternatives

Pick Nuclei when you only need to identify exposed Tomcat JMX proxies at scale or confirm a version string before deeper testing. jmx2rce includes a nuclei template, so the two tools pair well: Nuclei finds candidates, then jmx2rce validates impact on the specific host.

Pick Metasploit Framework when you want a general-purpose exploitation platform with staging, payload options, and post-exploitation modules. jmx2rce is narrower and more deterministic, which is better when the target is specifically Tomcat and you want to see the exact attribute changes.

Pick Burp Suite when the failure mode is unclear and you need to inspect requests, headers, redirects, and encoded payloads by hand. For adjacent terminal-first workflows, browse all CLI Tools or Security Testing tools if you want something that sits beside jmx2rce in a scripted lab.

How jmx2rce Works

jmx2rce talks directly to Tomcat's Manager JMX proxy over HTTP or HTTPS and treats the server as a set of writable MBeans rather than as a black-box web app. The attack chain starts with discovery, then moves through attribute mutation on the ROOT web module, the Connector, and the AccessLogValve, and ends with a restore step that puts the original values back.

The design is stateful by necessity. For file read, jmx2rce changes the ROOT docBase to a directory that already contains the target file, reloads the context, and fetches the file as if it were part of the app. For RCE, it changes the log destination and file suffix so Tomcat writes a JSP into the web root, then triggers a request that causes the server to compile and execute the page.

# discovery, file read, RCE, and cleanup
jmx2rce scan -H target.com
jmx2rce read -H target.com -p /etc/passwd
jmx2rce rce -H target.com -payload '${Runtime.getRuntime().exec("id")} '
jmx2rce cleanup -H target.com

The first command checks whether the Tomcat JMX proxy responds with server information. The second and third commands change Tomcat's runtime state just long enough to read a file or generate a JSP-backed payload, and the cleanup command restores the original docBase, valve configuration, and connector settings so the host is not left in a modified state.

The implementation choices are simple on purpose. jmx2rce uses Go's standard library instead of a large dependency graph, which keeps the binary small, avoids runtime package issues, and makes it easy to run in isolated environments where only curl-style HTTP behavior is allowed.

Pros and Cons of jmx2rce

Pros:

• Single static binary with no third-party runtime dependencies, which makes deployment fast and predictable.
• Clear operational phases (scan, read, rce, cleanup) that map to real Tomcat state changes.
• Works across macOS, Linux, and Windows, so the same binary can move between operator workstations and lab hosts.
• Includes a nuclei template for quick detection before you attempt a higher-risk exploit chain.
• Supports verbose logging and JSON output, which is useful when you are triaging multiple hosts.
• Explicit cleanup logic reduces the chance of leaving a modified Tomcat instance behind after testing.

Cons:

• Only applies to Tomcat deployments that expose the JMX proxy endpoint, so the target surface is narrow.
• The RCE path depends on Tomcat version details and EL behavior, especially the Tomcat 9+ with EL 3.0 case.
• The attack changes runtime configuration and can disrupt a live service if used carelessly.
• Cleanup can fail or need manual adjustment if the instance uses a nonstandard ROOT layout or customized valve settings.
• It is not a general exploit framework, so it will not help on unrelated Java stacks or application servers.

Getting Started with jmx2rce

Start by building the binary from source, then run a discovery scan against a host you are authorized to test. The repo also documents a prebuilt binary path, but the source build is straightforward because the project only needs Go 1.20+ and the standard library.

git clone https://github.com/hacktus/jmx2rce.git
cd jmx2rce/tool
go build -o jmx2rce jmx2rce.go
./jmx2rce -h

# first validation pass
./jmx2rce -scheme https -verify scan -H target.com

After the build, scan checks whether the JMX proxy is exposed and reports the Tomcat version when the endpoint answers. If you are working behind a proxy, the global flags matter: -scheme selects HTTP or HTTPS, -verify turns certificate validation on, and -header lets you add custom request headers for a lab or test harness.

If you want a broader sweep before targeting one host, the included nuclei template is the fast path for finding candidates. That lets you detect the endpoint at scale and then hand the confirmed hosts to jmx2rce for file read or RCE validation.

Verdict

jmx2rce is the strongest option for validating exposed Tomcat JMX proxy attacks when you need file-read and RCE coverage from a single static Go binary. Its biggest strength is the full save-mutate-restore workflow; its main caveat is that it only matters on misconfigured Tomcat instances. Use it when you have authorization and need proof, not guesses.