FastJson漏洞致Spring Boot全中招，在野攻击已出现

7月19日，安全研究员Kirill Firsov在推特上发了一条消息：他在Fastjson 1.2.83里发现了一个不需要gadget的RCE漏洞，附带了一段演示，一条payload打过去，直接拿到shell。

这块影响较大，1.2.83是Fastjson 1.x的最后一个版本，很多人当年都是特意升到这个版本的，升完就觉得这块不用再管了。

7月21日，阿里官方发布了安全公告，编号CVE-2026-16723，CVSS评分9.0，绿盟那边给的是9.8。我把官方公告、研究者的技术文档和几家安全厂商的报告都翻了一遍，这篇文章把事情的经过、影响范围和处理办法说清楚，还在用Fastjson 1.x的建议看完就去查一下。

这个漏洞和以前的Fastjson漏洞不一样

干Java的这些年，Fastjson的漏洞消息差不多每年都能看到。以前那些反序列化漏洞，利用起来基本都有前提：要么目标开了AutoType，要么classpath里得有能用的gadget类。所以这些年大家总结出来的防御经验就是两条：关掉AutoType，再把危险的依赖从项目里清出去。很多团队做完这两件事，就觉得Fastjson这块稳了。

但这次的漏洞不走这条路，问题出在Fastjson做类型解析时的资源探测逻辑上：它遇到不认识的类型名，会试着把这个名字当成类路径资源去加载一次，看看这个类上有没有@JSONType注解，有的话就当它是可信的。

攻击者构造的@type值经过Fastjson内部的字符替换之后，可以拼出一个指向远程服务器的地址，让应用自己去把攻击者的恶意类下载下来并加载。整个过程发生在正常的类型检查之前，所以关不关AutoType根本不影响，classpath里有什么也没有什么区别。

还有一点我觉得有必要单独说：

很多人现在的写法是 JSON.parseObject(body, 某个Dto.class) ，指定了目标类，觉得这样攻击者就没法随便指定类型了。官方公告里明确写了，这种写法挡不住，因为恶意内容可以藏在DTO里 Object 或者 Map 类型的字段里，照样能走到解析逻辑。也就是说，单纯代码写得规范，并不等于安全。

这个漏洞虽然评分高，但触发条件比较明确，一条一条对着查，就能知道自己的服务在不在范围里：

条件

Fastjson版本

官方CVE记录是1.2.68到1.2.83，腾讯云的通告里写的是1.2.37到1.2.83，几家给的范围不完全一样，建议按最宽的查

部署方式

必须是Spring Boot的可执行fat-JAR，用java -jar跑起来的那种。打war包部署到外部Tomcat的不受影响

SafeMode

没开（默认就是没开）

出网

服务器能访问外部HTTP，攻击者需要让目标下载远程的恶意JAR

入口

存在把外部传入的JSON交给Fastjson解析的接口，公网接口、回调、内网服务间调用都算

为什么偏偏是Spring Boot的fat-JAR，研究文档里解释得很清楚：fat-JAR用的是LaunchedURLClassLoader，它加载嵌套JAR的机制会把那种构造出来的远程地址真的解析成一次网络请求。普通方式跑的应用，同样的名字只会被当成本地路径，找不到就返回，链条走不下去。

JDK版本影响的是攻击效果，JDK 8下面一步到位，直接执行代码；JDK 9及以上因为类名校验更严，攻击者要分两步走，先把恶意JAR骗下载到本地，再引用下载下来的文件完成加载，研究者在8、11、17、21上都验证通过了，Windows上高版本JDK的两阶段打法走不通。

攻击已经在发生了

安全厂商Imperva在7月24日的报告里说，他们已经观测到针对这个漏洞的真实攻击，目标主要是美国的机构，新加坡和加拿大也有，涉及金融、医疗、IT、零售这些行业，金融占了28%，医疗占了22.9%。国内的微步在线（ThreatBook）也发了在野利用的告警。

PoC也已经公开了，GitHub上有人放出了完整的靶场和检测规则，在JDK 8、17、21、25上都复现成功。传播到国内只是时间问题，处理窗口其实就这么几天。

现在该做什么

先说一个坏消息：Fastjson 1.x的仓库在2024年10月就归档成只读了，官方不会再为1.x出修复版本，这次没有"等下个版本升级一下"这个选项，想等着官方修订版本然后不用改项目代码的兄弟可以打消这个想法了。

按轻重缓急，我建议这么处理：

排查

把公司所有Java服务过一遍，找出直接或者间接依赖Fastjson 1.x的，尤其注意间接依赖，很多老框架和内部SDK里会带，Spring Boot fat-JAR部署的优先处理。

止血

短期最有效的办法是开SafeMode，JVM参数加-Dfastjson.parser.safeMode=true，或者代码里ParserConfig.getGlobalInstance.setSafeMode(true)，它能直接掐断这条攻击链。

如果担心影响业务，可以先在测试环境验证。还有一个选择是换成1.2.83_noneautotype这个特殊版本，它在编译期就把AutoType相关的代码剔掉了。

限出网

应用服务器本来就不该随便访问外部HTTP，趁这个机会把出站策略收紧，就算漏了什么，攻击者也下载不了东西。

迁移

上面这些都只是止血，长期的答案只有一个：迁到Fastjson2，2.x的架构重写过，不受这个漏洞影响。迁移成本肯定有，API有变化，还有一些行为差异要测，但这次之后还留在1.x，就是等着下一次。

最后说两句

Fastjson 1.x这几年出的每个漏洞，社区的应对都是"升级到最新版加关掉AutoType"，这套办法让很多人对它产生了一种虚假的安全感，觉得1.2.83是个可以长期呆着的养老版本。

这次漏洞最麻烦的地方就在于它把这套经验整个作废了：默认配置就能触发，fat-JAR又恰恰是最主流的部署方式，受影响的入口也是大家天天在用的那几个解析方法。

说实话Fastjson也挺让人感慨的，性能确实好，当年确实是国产开源的骄傲，但1.x的设计包袱太重了，反序列化这块补了这么多年还是补不干净。仓库归档之后它就是个不会再更新的存量风险，这次只是正好爆出来而已。

如果你的团队还在用1.x，我的建议很简单：这周先把SafeMode开了，然后把迁移Fastjson2排进日程，别再往后拖了。