阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/fastjson-fatjar-rce-cve-2026-16723/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• 一、你背的那套 Fastjson 防御口诀，这次全失灵
• 二、”全部中招”看的是打包方式，不是代码水平
• 三、被打的是真实机构，不是靶机
• 四、方案第一页，先回答”我到底有没有在用它”
• 五、现在的作业，官方 P0/P1 翻译成人话
• 六、补丁其实已经发了，只是没人吭声
• 七、最后，把整改方案落成三行

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

7 月 19 日，研究员 Kirill Firsov 在推特上甩出消息，说 Fastjson 1.2.83 有个不需要 gadget 的远程代码执行漏洞，演示里一条 payload 打过去，shell 直接回来。

两天后阿里官方发公告，编号 CVE-2026-16723，CVSS 9.0（绿盟口径 9.8），影响 1.2.68 到 1.2.83。扎心的是 1.2.83 是 1.x 最后一个版本，很多人特意升上去就不管了。

现在要交整改方案，先别急着写”全面迁移”。下面把官方 P0/P1 清单翻译成人话。赶时间的跳到第五节抄作业，要写依据的把机制读完。

一、你背的那套 Fastjson 防御口诀，这次全失灵

干 Java 的都背过这套口诀。出漏洞，升级最新版、关掉 AutoType、清走危险依赖。以前的反序列化漏洞利用有前提，要么开了 AutoType，要么 classpath 里有能用的 gadget；口诀管用到大家觉得 1.2.83 能养老。

这次不走这条路。问题出在类型解析的资源探测，遇到不认识的类型名，Fastjson 会先把名字当类路径资源加载一次，看有没有 @JSONType 注解，有就信。这步在正常类型检查之前，AutoType 开不开无所谓，classpath 也无所谓。

攻击者构造的 @type 值，经内部字符替换能拼出远程服务器的地址，应用自己下载加载恶意类。损的细节是，类名里的点会被替换掉，域名拼不出来；但 IP 有整数写法，127.0.0.1 写成 2130706433，没有点，正好绕过去。

还有个侥幸，JSON.parseObject(body, 某个Dto.class) 指定目标类，很多人觉得就安全了。官方公告写得明白。挡不住，恶意内容藏在 DTO 的 Object 或 Map 字段里，照样走到解析逻辑。代码规范，不等于安全。

二、”全部中招”看的是打包方式，不是代码水平

漏洞要走通，”下载远程恶意类”必须真发出网络请求，这恰好是 fat-JAR 的特性，LaunchedURLClassLoader 加载嵌套 JAR 时，会把构造出的远程地址变成真实的网络请求。普通部署下同样的名字只是本地路径，返回 null，链条断掉；war 到外部 Tomcat 不满足触发条件。

JDK 版本决定利用方式，JDK 8 一条 payload 直接执行；JDK 9 及以上类名校验更严，得两步走，先把恶意 JAR 骗到本地，再经 /proc/self/fd 引用加载。描述符编号要一个个枚举，研究者让 Claude 批量生成探测类试出来的。

研究者在 JDK 8、11、17、21 验证通过，Spring Boot 2.x 到 4.x 都中招。”一条 payload 拿 shell”要看容器和类加载器组合，默认 Tomcat 加现代 JDK 要两段式，但两段式也通；Windows 高版本 JDK 走不通，是边界不是护身符。

三、被打的是真实机构，不是靶机

Imperva 7 月 24 日报告已观测到真实攻击，目标主要是美国机构，新加坡和加拿大也有，行业集中在金融、医疗、IT、零售，图里金融占 28%、医疗 22.9%。微步在线也发了在野告警。

攻击门槛还在降，PoC 已公开，GitHub 上有完整靶场和检测规则，约两百 Star，JDK 8、17、21、25 都复现成功。披露到今天满一个月，别再拿”等传到国内”安慰自己。

四、方案第一页，先回答”我到底有没有在用它”

触发条件很明确，五条打勾，全中才在范围内。

自查项	判断标准
Fastjson 版本	官方口径 1.2.68-1.2.83，腾讯云写到 1.2.37 起，几家不一致按最宽查
部署方式	Spring Boot 可执行 fat-JAR（java -jar）；war 到外部 Tomcat 不在内
SafeMode	没开（默认就是没开）
出网	能访问外部 HTTP（攻击者需要它下载远程 JAR）
入口	有接口把外部 JSON 交给 Fastjson 解析，公网、回调、内网都算

版本这关最容易翻车，fastjson 常不是你引进的，老框架、内部 SDK 一藏一个准。

更麻烦的是工具会失明，生产机只有 fat-jar 没有 pom，依赖树跑不了；被 shade 进厂商 SDK 的，树上根本不出现。

方案第一页别写”建议升级”，先写怎么确认。修复这个漏洞只需要一个下午，难的是先回答”我到底有没有在用它”。

五、现在的作业，官方 P0/P1 翻译成人话

官方按 P0、P1 排好队，即按改动成本从低到高。

第 0 步，摸清依赖

先跑依赖树。

mvn dependency:tree -Dincludes=com.alibaba:fastjson

依赖树有盲区时，用 fastjson-check 扫产物。

java -jar fastjson-check.jar ./myapp.jar

输出 [CRITICAL] fastjson 1.2.83 加 BOOT-INF 路径即实锤，fat-JAR 部署优先处理。

第 1 步（P0），升级到 1.2.84

改成 com.alibaba:fastjson:1.2.84，同分支小版本，通常不改代码。

第 2 步（P0），开 SafeMode

加启动参数。

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

改不了启动脚本就用代码，ParserConfig.getGlobalInstance().setSafeMode(true)，拒绝所有 @type、掐断攻击链；担心影响业务，先在测试环境验证。

第 3 步，noneautotype 和限出网

换 com.alibaba:fastjson:1.2.83_noneautotype，编译期剔掉 AutoType 代码。同时收紧出站，攻击链必须下载远程 JAR，限出网就下载不了。

长期（P1），迁 Fastjson2，底线 2.0.63

2.x 架构重写，不受本漏洞影响，但 API 有变、行为要测，要排期。

必记两条。一是迁移目标 ≥2.0.63；二是低版本另有长亭报告的 9.8 分加固问题，2.0.63 才修复。它的 SafeMode 参数名也不同，是 -Dfastjson2.parser.safeMode=true。留在 1.x，就是等下一次。

六、补丁其实已经发了，只是没人吭声

7 月 29 日上午，中文安全圈还在说”1.x 仓库 2024 年 10 月就归档只读，官方不会再修，只能迁移”。这话上午还是对的。当天下午，官方破例解档发布 1.2.84，发完又归档回去。

为什么这么多人错过？两个传播事故撞在一起。1.2.84 的 release 标题没标”安全修复”，完整说明只在正文里；GHSA 的修复版本字段至今是空的，扫描器只说”中招了”，不说升到哪。

工具不指路，群友传旧结论，一个下午的 P0 被写成了三个月项目。

七、最后，把整改方案落成三行

Fastjson 每次出漏洞，社区的应对都是”升级最新版加关 AutoType”，久了就把 1.2.83 当成养老版本。这次这套经验整个作废，默认配置就能触发、fat-JAR 是最主流的部署方式、受影响入口是天天在用的解析方法。

Fastjson 也让人感慨，性能确实好，当年是国产开源的门面，两万五千多 Star 的仓库，如今归档只读，成了实质停更的存量风险。1.2.83 曾被当成安全终点，归档后成了不再常规维护的终点。

所以这份方案就三行。

• 现在，升级 1.2.84，升不动就开 SafeMode；
• 顺手，把出站策略收紧；
• 排期，迁移 Fastjson2（≥2.0.63）进日程，别再拖。（强烈建议，芋道开发平台，就采用了这个方案！！！）