Fastjson 1.x曝出9.0分RCE漏洞！Spring Boot项目赶紧自查，官方补丁还没出
- 经验分享
- 时间：2026-07-28 15:59
- 11人已阅读
🔔🔔好消息!好消息!🔔🔔
有需要的朋友👉:微信号
Fastjson 1.x曝出9.0分RCE漏洞！Spring Boot项目赶紧自查，官方补丁还没出
原创:凯哥Java
本文标签:Fastjson漏洞、CVE-2026-16723、Spring Boot安全、Java RCE
大家好，我是凯哥Java。
做Java开发这么多年，说到Fastjson，大家应该都不陌生。国产JSON解析库的扛把子，几乎每个Java项目里都能看到它的身影。阿里出品，性能强，解析快，很多老项目从Fastjson 1.x一路用下来，到现在还在用。
但就在这两天，安全圈爆了一个重磅消息——Fastjson 1.x曝出新的高危RCE漏洞，CVSS评分高达9.0分，而且攻击者已经开始在野外利用了！
更让人头疼的是：官方正式补丁还没出。你手里的代码可能正在裸奔。
今天凯哥就带大家看看这个漏洞怎么回事，以及你现在该做什么。
摘要内容:Fastjson 1.x（1.2.68~1.2.83版本）曝出9.0分RCE漏洞CVE-2026-16723，无需AutoType无需Gadget链，攻击者仅需一个恶意JSON请求就能远程执行任意命令。当前已有野外利用证据，阿里官方尚未发布正式补丁。
一、这次漏洞到底有多猛？一个JSON就能拿下系统
熟悉Fastjson安全历史的同学都知道，过去Fastjson爆出过不少RCE漏洞，但绝大多数都有一个前提：要么得开AutoType，要么得依赖特定的利用链（gadget）。这也让很多团队觉得"关了AutoType就万事大吉"。
但这次不一样。
生活中的例子：
想象一下，你家装了大门（Fastjson解析器），过去的小偷要进门得先找到钥匙串（特定gadget链），还得把大门上的安全锁打开（开启AutoType）。但这次，小偷发现你家墙上有个暗门，不用钥匙不用开锁，直接推门就能进。
总结：
以往的Fastjson漏洞需要条件触发，但CVE-2026-16723打破了这些限制——无需开启AutoType，不需要classpath里有特定gadget库，只要满足一个条件（后面会说），构造一个恶意JSON请求，就能直接远程执行任意系统命令，权限等同于Java进程权限。
这次漏洞的核心参数：
| 项目 | 内容 |
|---|---|
| 漏洞编号 | CVE-2026-16723 |
| CVSS评分 | 9.0（高危） |
| 影响版本 | Fastjson 1.2.68 ~ 1.2.83 |
| 是否需要AutoType | ❌ 不需要 |
| 是否需要gadget链 | ❌ 不需要 |
| 攻击方式 | 恶意JSON请求 → 任意代码执行 |
| 攻击前提 | Spring Boot可执行fat-JAR |
尤其要警惕的是，1.2.83这个版本——很多人以为是"安全版本"才升上来的，结果恰恰落在受影响范围内。
二、漏洞原理三句话说清
这个漏洞由FearsOff Cybersecurity的研究员Kirill Firsov发现并负责任的披露。
凯哥不堆术语，三句话讲清楚：
第一句：漏洞出在Fastjson的@type参数解析逻辑上。攻击者可以在JSON请求里塞一个恶意@type，让Fastjson去尝试加载这个类。
第二句：在Spring Boot的fat-JAR特殊加载机制下，嵌套Jar路径可以被攻击者利用，加载他自己写的恶意字节码。
第三句：恶意类里的@JSONType注解会被Fastjson当成"自己人"的标识，跳过类型校验直接信任，完成恶意类加载。
⚠️ 研究团队还发现，高版本JDK下存在一条利用/proc/self/fd加载远程Jar文件的备选攻击路径，影响面更广。
三、哪些系统在劫难逃？Spring Boot fat-JAR首当其冲
这次漏洞的攻击条件有一个关键的"触发器"——Spring Boot可执行fat-JAR包。
高风险的部署形态：
| 部署方式 | 风险等级 |
|---|---|
| Spring Boot fat-JAR直接运行 | 🔴 高危 |
| Spring Boot 2.x/3.x/4.x + JDK8/11/17/21 | 🔴 高危 |
| 非fat-JAR的普通Jar | 🟢 不受影响 |
| WAR包部署在Tomcat/Jetty | 🟢 不受影响 |
| 通用uber-JAR | 🟢 不受影响 |
风险入口：JSON.parse()、JSON.parseObject()等常见解析接口。
⚠️ 就算你的代码里用了固定类来接收JSON，但如果这个类内部包含Object、Map类型的字段，攻击者依然可以通过嵌套方式注入恶意载荷。不是入参固定了就安全了。
四、野外攻击已经发生，别等官方补丁了
这不是理论漏洞。攻击者已经开始动手了。
ThreatBook（微步在线）实验室在7月22日确认捕获到真实环境的野外利用行为：在JDK8 + Spring Boot fat-JAR环境下成功复现了完整RCE。如果是内嵌Tomcat部署的场景，虽然拿不到完整代码执行权限，但可以实现远程Jar拉取或SSRF攻击。
Imperva的监测数据更值得警惕——攻击目标行业分布如下：
| 行业 | 攻击量占比 |
|---|---|
| 💰 金融服务业 | 最高 |
| 🏥 医疗 | 第二 |
| 💻 计算/IT | 第三 |
| 🏪 零售 | 第四 |
| 🏢 商业企业 | — |
| 🎮 文娱 | — |
| 📡 电信运营商 | — |
攻击主体集中在美国，新加坡和加拿大也有少量攻击流量。大部分攻击请求使用了伪装浏览器头的自动化工具，其中Ruby和Go编写的攻击工具合计占比约30%。
截止7月25日，阿里官方尚未发布修复该漏洞的Fastjson 1.x正式新版本，Maven仓库和GitHub标签均无完整补丁版本。
五、凯哥的应急三步走：赶紧照做
第一步：长期根治 → 迁移到Fastjson2
Fastjson2的底层逻辑与1.x完全不同，不存在同样的资源探测与注解信任机制，天然不受该漏洞影响。
// pom.xml 替换依赖 <dependency> <groupId>com.alibaba.fastjson2</groupId> <artifactId>fastjson2</artifactId> <version>2.0.53</version> </dependency>
同时注意，Fastjson2的包名和API都有变化，导入改成：
import com.alibaba.fastjson2.JSON; // 原来是：import com.alibaba.fastjson.JSON;
如果项目用了1.x特有的扩展功能，建议在测试环境充分验证后再切。
第二步：临时防护（无法立刻迁移业务的二选一）
方案A：JVM启动参数开启安全模式
java -Dfastjson.parser.safeMode=true -jar your-app.jar
这个参数会全局关闭Fastjson的类型自动解析，阻止攻击者通过@type注入恶意类。配置简单，生效快，适合临时止血。
方案B：切换受限版本依赖
<dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.83_noneautotype</version> </dependency>
这个版本禁用了AutoType，虽然不能100%防护本次漏洞，但可以降低一部分攻击面。
第三步：企业自查与排查
全面梳理Fastjson 1.x资产
查项目直接依赖和传递依赖
Maven命令：
mvn dependency:tree | grep fastjsonGradle命令：
gradle dependencies | grep fastjson
审计Web访问日志
重点排查请求中出现异常
@type、嵌套Jar地址的访问记录
监控异常行为
服务器异常出站连接
陌生子进程启动
新增可疑文件
WebShell等后门行为
结束语
大家好，我是凯哥Java(kaigejava)，乐于分享技术文章，欢迎大家关注"凯哥Java"，及时了解更多。让我们一起学Java。也欢迎大家有事没事就来和凯哥聊聊~~~
如果你最近想排查项目里的Fastjson版本、做安全自查、或者正在考虑从Fastjson 1.x迁移到Fastjson2，这篇应急方案非常值得参考。9.0分的RCE漏洞，官方补丁没出之前，安全模式先开上。
CVE-2026-16723应急修复方案
Fastjson RCE漏洞影响版本范围
Spring Boot fat-JAR安全风险排查
Java JSON库迁移Fastjson2实操
企业级漏洞应急响应指南
CVE-2026-16723 Fastjson RCE Spring Boot 安全模式 漏洞排查指南
Fastjson2迁移避坑 Java企业安全应急响应 临时止血方案
Spring Boot fat-JAR JSON解析漏洞 官方补丁未出怎么办
作者:凯哥Java
类型:原创
标签:Fastjson漏洞、Spring Boot安全、Java RCE、企业应急、运维指南
原创声明:本文原创发表于「凯哥Java」公众号，转载请注明出处。