Fastjson高危漏洞紧急修复指南

2026年8月，Fastjson再次被曝出严重安全漏洞，编号CVE-2026-16723（国内编号QVD-2026-43021），CVSS评分高达9.8，属于远程代码执行级别的高危风险。

攻击者只需构造一段精心设计的恶意JSON请求，无需任何前置权限，就能在目标服务器上执行任意系统命令，直接拿下整个项目的控制权。

很多人第一反应是"我项目里早就不用Fastjson了"。但现实情况是，大量老Spring Boot项目的依赖树里，Fastjson可能正以间接依赖的方式悄悄躺着，你压根没察觉到它的存在。

本篇文章把漏洞影响范围、自查步骤和修复方案一次性讲清楚，照着操作就能把风险堵上。

01

这个漏洞到底有多狠？

漏洞出在Fastjson的反序列化核心逻辑中。攻击者不需要任何前置条件，只要向你的接口发送一个特制的JSON数据包，就能触发远程代码执行，完成以下高危操作：

• 下载执行恶意脚本，将服务器变成"肉鸡"

• 窃取数据库配置、用户敏感数据等核心信息

• 删除业务文件，直接导致线上服务瘫痪

• 穿透内网，攻击同集群内的其他服务

即使项目中没有显式使用Fastjson进行序列化操作，只要依赖版本在风险范围内，同样可能被攻击命中。

目前互联网上已出现公开的PoC验证脚本，黑客开始批量扫描全网存在漏洞的Spring Boot服务。现在不处理，线上随时可能出问题。

02

先自查：你的项目有没有中招？

很多人第一反应是去pom.xml里搜Fastjson坐标，但这样做会漏掉间接依赖。以下两个方法可以100%准确排查：

方法一：Maven命令一键扫描

在项目根目录执行：

mvn dependency:tree |grep fastjson

如果输出了Fastjson版本号，且版本在1.2.68 ~ 1.2.83之间，就在本次漏洞影响范围内，必须处理。

方法二：代码验证漏洞是否可触发

在任意Spring Boot接口中临时加一段测试代码，启动后用Postman发送恶意JSON请求验证：

@RestController
@RequestMapping("/test")
publicclass VulnerabilityCheckController {
    @PostMapping("/fastjsonCheck")
    publicString checkVulnerability(@RequestBodyString jsonStr) {
        try { // 直接用Fastjson解析传入的JSON 
            JSON.parse(jsonStr);
            return"解析完成";
        } catch (Exception e) {
            return"解析异常";
        }
    }
}

如果发送构造的恶意JSON后服务器出现异常执行痕迹，说明项目存在被利用风险，必须马上修复。

03

修复方案：三种场景对号入座

根据项目情况选择对应的修复方式：

场景一：项目直接依赖了Fastjson

如果项目里明确写了Fastjson依赖，建议直接迁移到Fastjson 2.x。1.x系列已在2024年停止维护，官方不会再为1.x发布安全补丁。

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

同时全局替换import：com.alibaba.fastjson → com.alibaba.fastjson2。

如果暂时无法迁移，可先开启SafeMode临时止血：

@PostConstructpublicvoidenableSafeMode() {
    ParserConfig.getGlobalInstance().setSafeMode(true);
}

SafeMode会禁用@type，直接截断漏洞触发链路。代价是业务中如果使用了Fastjson的多态反序列化功能，会受到影响，上线前务必验证。

场景二：Fastjson是间接依赖引入的

第三方工具包或SDK可能偷偷带入了Fastjson。在对应依赖中排除旧版本，再手动引入安全版本：

<dependency>
    <groupId>com.xxx.thirdpart</groupId>
    <artifactId>common-utils</artifactId>
    <version>2.3.0</version>
    <exclusions>
        <exclusion>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
        </exclusion>
    </exclusions>
</dependency><!-- 迁移到Fastjson 2.x -->
<dependency>
    <groupId>com.alibaba.fastjson2</groupId>
    <artifactId>fastjson2</artifactId>
    <version>2.0.61</version>
</dependency>

场景三：可以彻底替换Fastjson

如果项目没有强依赖Fastjson的特殊功能，直接切换到Spring Boot默认的Jackson是最彻底的方案：

@ConfigurationpublicclassJacksonConfigimplementsWebMvcConfigurer {
    @OverridepublicvoidconfigureMessageConverters(List < HttpMessageConverter < ? >> converters) {
        converters.removeIf(converter-> converterinstanceofFastJsonHttpMessageConverter);
    }
}

从根源上杜绝所有Fastjson相关的安全风险。

04

修复后务必验证

升级完成后，必须做两个验证：

验证一：检查依赖版本

再次执行：

mvn dependency:tree |grep fastjson

确认所有Fastjson相关依赖已被排除，没有残留的低版本。

验证二：重新发送PoC请求

用之前的测试接口再次发送恶意JSON，确认漏洞已无法触发。

05

最后提醒

做后端这么多年，见过太多因忽略组件漏洞导致线上被入侵的事故。有人觉得"项目小没人会攻击"，但现在黑客都用脚本全网批量扫描，根本不关心项目规模，有漏洞就会被盯上。

建议所有Java开发者今天之内把手里的Spring Boot项目全部自查一遍。10分钟的操作，就能避免后续可能要花几天几夜去处理的线上事故。

• 影响版本：Fastjson 1.2.68 ~ 1.2.83

• 修复方案：迁移到Fastjson 2.x，或开启SafeMode

• 漏洞编号：CVE-2026-16723 / QVD-2026-43021

• CVSS评分：9.8