最近安全圈被一颗重磅炸弹炸开了锅。阿里巴巴开源的 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 URLjar: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 已经 EOLEnd of Life指望官方发补丁是不现实的。以下几个动作建议尽快落实优先级从高到低立刻启用安全模式。在启动参数里加上-DFastJson.parser.safeModetrue或者在代码里通过等效属性开启。安全模式下 FastJson 会禁用所有自动类型相关功能这是目前 1.x 版本下最有效的临时止血手段。排查依赖全景。用mvn dependency:tree或 Gradle 的依赖报告把项目里所有直接和传递引入的 FastJson 1.x 依赖都列出来。注意有些中间件或第三方 SDK 可能内部打包了 FastJson这种隐式依赖最容易被漏掉。规划迁移到 FastJson 2.x。这是中长期的最优解。2.x 不仅修复了这类类型解析缺陷整体架构也更现代化。迁移前务必做好兼容性测试尤其是如果你们大量使用了自定义序列化器或特定注解。审查访问日志。重点检索包含type字段的 JSON 请求体以及任何出现jar:http或jar:fileURL 模式的输入。这些往往是攻击尝试的指纹。如果发现有可疑请求结合 WAF 规则做紧急拦截。写在最后FastJson 的这次漏洞再次给 Java 社区敲响了警钟。一个被无数项目依赖的基础库一旦在类型解析这种核心机制上出问题波及面是灾难性的。更残酷的是1.x 的维护终止让大量存量系统陷入了无补丁可打的尴尬境地。对于安全团队来说接下来的几周是关键期。扫描、加固、迁移三件事没有一件能拖。对于还在用 FastJson 1.x 的开发者建议今天就把安全模式打开明天开始排迁移计划。在漏洞利用代码已经公开、攻击流量已经出现的当下再看看的代价可能是整个应用集群的沦陷。