Fastjson 1.x曝出9.0分RCE漏洞！Spring Boot项目赶紧自查，官方不再出补丁了

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分支已经正式EOL（End of Life，即停止维护）了，你再等也等不到官方补丁。这不是"补丁还没出"，是"不会再出了"。

留给你修补的时间窗口，比想象中更窄。

摘要内容:Fastjson 1.x（1.2.68~1.2.83版本）曝出9.0分RCE漏洞CVE-2026-16723，无需AutoType无需Gadget链，攻击者仅需一个恶意JSON请求就能远程执行任意命令。因Fastjson 1.x已停止维护（EOL），官方不再发布补丁。目前已有野外利用证据，建议开启安全模式并迁移Fastjson2。

一、这个漏洞到底有多严重？9.0分只是开始

先看一组硬数据。CVE-2026-16723，CVSS v3评分9.0分，属于Severity级别。奇安信内部编号QVD-2026-43021，估计有数百万个线上实例处于风险之中。

凯哥之前也说很多漏洞需要AutoType开启、需要特定gadget链才能利用，但这次完全不一样。

生活中的例子：

想象一下你住的小区，之前有小偷要进来得先绕过门禁（关闭AutoType），再找到特定户型才能得手（gadget链）。但这次，小偷发现小区围墙有个洞，不用刷门禁卡，不用挑户型，随手一推就能进到任何一家。

总结：

CVE-2026-16723在Fastjson的默认配置下就能被触发。攻击者不需要诱导管理员开启AutoType，不需要往classpath里塞任何第三方gadget类。过去那种"关了AutoType就安全了"的经验法则，在这个漏洞面前完全失效。

二、漏洞原理：默认配置下的安全黑洞

要理解这个漏洞，得先回顾一下Fastjson的工作机制。

Fastjson支持通过@type字段做多态反序列化——简单说，就是JSON里写一个类名，Fastjson会尝试实例化这个类。1.x版本里，AutoType默认是关闭的，并且有一整套黑名单机制来拦截危险类。

但CVE-2026-16723走的是另一条路。

研究人员发现，Fastjson的内部类型解析逻辑存在一条被忽视的旁路。攻击者构造的恶意JSON中，@type字段指向一个看似无害的类名，Fastjson在处理过程中会执行资源查找操作。

利用路徑拆解：

1️⃣ 攻击者构造恶意JSON请求，在@type中填充目标类名

2️⃣ Spring Boot fat-JAR的特殊加载机制下，嵌套Jar路径可以被利用加载恶意字节码

3️⃣ 恶意类上的@JSONType注解被Fastjson当成"信任信号"，跳过类型校验直接加载

4️⃣ 攻击成功 → 远程执行任意系统命令，权限等同于Java进程权限

研究团队还发现，高版本JDK下存在一条利用/proc/self/fd加载远程Jar文件的备选攻击路径，影响面更广。

三、哪些项目在劫难逃？Spring Boot fat-JAR首当其冲

很多开发者可能觉得"我用的是Jackson不是Fastjson，不关我事"。但问题是，Fastjson经常作为传递依赖悄悄躺在你的classpath里——某个中间件用了、某个第三方SDK内置了、甚至你自己都不知道。

高风险部署形态：

风险入口：JSON.parse()、JSON.parseObject()等常见解析接口。即便入参绑定固定类，如果对象内部包含Object、Map类型的字段，攻击者依然可以嵌套注入恶意载荷。

四、攻击者已经在行动了，别停留在"理论风险"

这可不是"纸上谈兵"的漏洞。完整的PoC利用代码已经在网上公开，攻击者已经开始大规模利用。

ThreatBook（微步在线）实验室在7月22日确认捕获到真实环境的野外利用行为：JDK8 + Spring Boot fat-JAR环境下成功复现了完整RCE。

Imperva全球威胁情报网络的监测数据显示，针对这个漏洞的利用活动正在持续升温——

这种"广撒网"式的扫描利用，意味着攻击者已经把PoC集成进了自动化武器库，暴露在互联网上的Fastjson应用随时可能被扫描到。

五、凯哥应急三步走：今天就得办的事

关键前提先说清：Fastjson 1.x已经EOL，官方不会再发布1.x的补丁。别等了，按下面的顺序操作。

第一步：立刻启用安全模式（今天做了再说）

这是Fastjson 1.x下最有效的临时止血手段。在JVM启动参数里加上：

java -Dfastjson.parser.safeMode=true -jar your-app.jar

安全模式下，Fastjson会禁用所有自动类型解析功能，攻击者的@type注入直接就废了。生效快、影响小，适合第一时间止血。

第二步：全面排查Fastjson 1.x依赖资产

很多团队用了Fastjson但自己都不知道——它是作为传递依赖进来的。查清楚到底有多少资产暴露在风险中：

# Maven项目
mvn dependency:tree | findstr fastjson

# Gradle项目  
gradle dependencies | findstr fastjson

排查要点：

• ✅ 直接依赖：pom.xml里显式声明的fastjson
• ✅ 传递依赖：中间件/第三方SDK内部引入的fastjson
• ✅ 内嵌依赖：某些框架把fastjson打包在自身Jar里的

如果项目还在用1.2.83（很多人以为这是"安全版本"才升上来的），请注意它正好在受影响范围内。

第三步：规划迁移到Fastjson 2.x（中长期最优解）

Fastjson 2.x底层逻辑完全不同，采用了优先允许列表（allowlist）的类型解析模型，从根本上改变了信任机制，这条攻击路径在2.x里走不通。

<dependency>
    <groupId>com.alibaba.fastjson2</groupId>
    <artifactId>fastjson2</artifactId>
    <version>2.0.53</version>
</dependency>

导入注意包名变化：

// Fastjson 1.x
import com.alibaba.fastjson.JSON;

// Fastjson 2.x
import com.alibaba.fastjson2.JSON;

如果项目大量使用了自定义序列化器或特定注解，迁移前务必做好兼容性测试。

附赠：日志审计检查项

除了上述操作，凯哥建议同步审计一下Web访问日志，重点关注：

1. 请求中出现异常@type字段的JSON请求体
2. 任何出现jar:http://或jar:file:// URL模式的输入
3. 服务器异常出站连接、陌生子进程、可疑文件新增

这些往往是攻击尝试的指纹，如果发现可疑请求，结合WAF规则做紧急拦截。

结束语

Fastjson这次漏洞再次给Java社区敲响了警钟。一个被无数项目依赖的基础库，一旦在类型解析这种核心机制上出问题，波及面是灾难性的。更残酷的是，1.x的EOL让大量存量系统陷入了"无补丁可打"的尴尬境地。

扫描、加固、迁移，三件事没有一件能拖。在漏洞利用代码已经公开、攻击流量已经出现的当下，"再看看"的代价，可能是整个应用集群的沦陷。

大家好，我是凯哥Java(kaigejava)，乐于分享技术文章，欢迎大家关注"凯哥Java"，及时了解更多。让我们一起学Java。也欢迎大家有事没事就来和凯哥聊聊~~~

如果你最近在排查项目里的Fastjson版本、做安全自查、或者正在考虑从Fastjson 1.x迁移到Fastjson2，这篇应急方案非常值得参考。9.0分的RCE漏洞，1.x已EOL，安全模式先开上，迁移计划排上日程。

CVE-2026-16723应急修复方案

Fastjson 1.x EOL无补丁应对策略

Spring Boot fat-JAR安全风险排查

Java JSON库迁移Fastjson2实操

企业级漏洞应急响应指南

CVE-2026-16723 Fastjson RCE Spring Boot 安全模式 1.x EOL 迁移Fastjson2

Fastjson2迁移避坑 Java企业安全应急响应 无官方补丁怎么办

Spring Boot fat-JAR JSON解析漏洞 停止维护版本安全指南

作者:凯哥Java

类型:原创

标签:Fastjson漏洞、Spring Boot安全、Java RCE、企业应急、运维指南

原创声明:本文原创发表于「凯哥Java」，转载请注明出处。