FastJson 爆出新 RCE 漏洞：数百万 Spring Boot 应用面临被攻陷风险

最近安全圈被一颗重磅炸弹炸开了锅。阿里巴巴开源的 FastJson 库曝出一个评分高达 9.0 的远程代码执行漏洞，编号 CVE-2026-16723。这不是又一次"理论上存在风险"的纸面警告——完整的技术细节和可直接运行的 PoC 利用代码已经在网上公开，Imperva 的监测数据更是证实：攻击者正在大规模利用这个漏洞。

对于还在用 FastJson 1.x 版本的开发团队来说，留给你们修补的时间窗口，可能比想象中更窄。

这个漏洞到底多严重？

先来看一组硬数据。CVSS v3 评分 9.0，属于"严重"级别。EPSS（漏洞利用预测评分）30 天内达到 0.4%，虽然数字看起来不大，但考虑到 FastJson 在国内 Java 生态中的普及程度，实际暴露面远超想象。

奇安信给这个漏洞的内部编号是 QVD-2026-43021，他们估计有数百万个线上实例处于风险之中。更棘手的是，FastJson 1.x 分支已经停止维护——这意味着官方不会为 1.x 发布补丁。你没法等一个"升级到新版本就万事大吉"的简单方案。

为什么偏偏是 FastJson？

很多开发者可能会问：Java 世界里 JSON 库那么多，Jackson、Gson 都在用，为什么 FastJson 一出事就闹得这么大？

答案藏在它的生态位里。FastJson 由阿里巴巴开源，凭借出色的性能和简洁的 API，早年间几乎成了国内 Java 项目的"默认选项"。无数 Spring Boot 服务把它集成在底层，有些是通过显式依赖引入的，更多则是作为传递依赖悄悄躺在 classpath 里。很多团队甚至不知道自己用了 FastJson——直到漏洞警报响起。

这次 CVE-2026-16723 最阴险的地方在于：它在 FastJson 的默认配置下就能被触发。攻击者不需要诱导管理员开启 AutoType，也不需要往类路径里塞任何第三方 gadget 类。过去那种"关掉 AutoType 就安全了"的经验法则，在这个漏洞面前完全失效。

攻击是怎么发生的？

要理解这个漏洞的利用路径，得先回顾一下 FastJson 的工作机制。

FastJson 支持通过 @type 字段做多态反序列化——简单说，就是 JSON 里写一个类名，FastJson 会尝试实例化这个类。1.x 版本里，AutoType 默认是关闭的，并且有一整套黑名单机制来拦截危险类。按说这套防御体系已经经历过多次漏洞洗礼，修修补补也算严密。

但 CVE-2026-16723 走的是另一条路。研究人员发现，FastJson 的内部类型解析逻辑存在一条被忽视的旁路。攻击者构造的恶意 JSON 中，@type 字段指向一个看似无害的类名，FastJson 在处理过程中会执行资源查找操作。当应用以 Spring Boot 胖 JAR 方式部署时，攻击者可以构造嵌套的 JAR URL（jar:http:// 或 jar:file:// 格式）来绕过类型检查，最终达成代码执行。

更糟的是，FastJson 会把类上的 @JSONType 注解当作一种"信任信号"。如果攻击者能找到带有这个注解的特定类，就能进一步放大攻击面。FearsOff 团队发布的分析报告把这个链条拆解得很清楚，FastJson 官方的安全通告也确认了这套机制。

一旦利用成功，未经身份验证的远程攻击者就能以应用进程的权限执行任意代码。数据窃取、WebShell 植入、凭证泄露、整台服务器被接管——这些后果都不是危言耸听。网上已经有公开的 PoC 实验室复现了完整攻击流程。

攻击者已经在行动了

Imperva 全球威胁情报网络的监测数据显示，针对这个 FastJson RCE 漏洞的利用活动正在持续升温。被攻击的行业覆盖面相当广——金融、医疗、计算机服务、零售，几乎无所不包。从地域分布看，美国是重灾区，新加坡和加拿大也出现了零星的攻击事件。

这种"广撒网"式的扫描利用，通常意味着攻击者已经把 PoC 集成进了自动化武器库。对于暴露在互联网上的 FastJson 应用，可能在你读到这篇文章的时候，就已经有人在敲门了。

哪些版本会中招？

受影响的范围是 FastJson 1.2.68 到 1.2.83，包括 1.x 的最后一个版本。FastJson 维护团队已经在 Spring Boot 2.x、3.x、4.x 以及 JDK 8、11、17、21 上全部验证过漏洞可利用。

好消息是，FastJson 2.x 不受影响。2.x 采用了优先允许列表（allowlist）的类型解析模型，从根本上改变了信任机制，这条攻击路径在 2.x 里走不通。

现在该做什么？

FastJson 1.x 已经 EOL（End of Life），指望官方发补丁是不现实的。以下几个动作建议尽快落实，优先级从高到低：

立刻启用安全模式。 在启动参数里加上 -DFastJson.parser.safeMode=true，或者在代码里通过等效属性开启。安全模式下 FastJson 会禁用所有自动类型相关功能，这是目前 1.x 版本下最有效的临时止血手段。

排查依赖全景。 用 mvn dependency:tree 或 Gradle 的依赖报告，把项目里所有直接和传递引入的 FastJson 1.x 依赖都列出来。注意，有些中间件或第三方 SDK 可能内部打包了 FastJson，这种"隐式依赖"最容易被漏掉。

规划迁移到 FastJson 2.x。 这是中长期的最优解。2.x 不仅修复了这类类型解析缺陷，整体架构也更现代化。迁移前务必做好兼容性测试，尤其是如果你们大量使用了自定义序列化器或特定注解。

审查访问日志。 重点检索包含 @type 字段的 JSON 请求体，以及任何出现 jar:http 或 jar:file URL 模式的输入。这些往往是攻击尝试的指纹。如果发现有可疑请求，结合 WAF 规则做紧急拦截。

写在最后

FastJson 的这次漏洞再次给 Java 社区敲响了警钟。一个被无数项目依赖的基础库，一旦在类型解析这种核心机制上出问题，波及面是灾难性的。更残酷的是，1.x 的维护终止让大量存量系统陷入了"无补丁可打"的尴尬境地。

对于安全团队来说，接下来的几周是关键期。扫描、加固、迁移，三件事没有一件能拖。对于还在用 FastJson 1.x 的开发者，建议今天就把安全模式打开，明天开始排迁移计划。在漏洞利用代码已经公开、攻击流量已经出现的当下，"再看看"的代价，可能是整个应用集群的沦陷。