2026 年 7 月 21 日，阿里巴巴官方发布高危漏洞预警，Fastjson 1.2.68 至 1.2.83 版本中存在评分为 CVSS 9.0 的远程代码执行漏洞（CVE-2026-16723）。由于 1.2.83 属于 Fastjson 1.x 分支的最终停止维护版本，截至 7 月 25 日，官方尚未针对该漏洞发布任何修复补丁。
漏洞研究人员 Kirill Firsov 证实，攻击者无需开启 AutoType，也不依赖特定的 Classpath Gadget 即可触发攻击。在 Spring Boot fat-JAR 的常见部署模式下，任意解析攻击者可控 JSON 字符串的网络端点均沦为攻击入口。这一漏洞彻底击穿了长期以来社区对「关闭 AutoType 即安全」的心理防御。
默认配置下直接 RCE：Fastjson 1.x 终版引发安全震荡
以往 Fastjson 的反序列化漏洞大多需要配置 AutoType 显式开启，或者依赖攻击者在目标 Classpath 中寻找特定的黑名单外 Gadget 类。CVE-2026-16723 打破了这一限制，直接在 Fastjson 的开箱即用默认配置下激活了远程代码执行能力。
受影响的版本范围精准覆盖了从 1.2.68 到 1.2.83 的所有 1.x 最终迭代版本。这说明缺陷代码逻辑已经在类型解析核心模块中隐匿运行了数年之久，影响了全网海量的生产服务。
图：Fastjson 漏洞报告与影响版本说明。来源：The Hacker News
只要服务端调用 JSON.parse 或 JSON.parseObject 解析外界传入的 JSON 数据，且目标绑定类型包含 Object 或 Map 等泛型字段，内部嵌套的恶意 Payload 就能完成注入。即便开发者将输入严格绑定到固定业务类，也无法阻断嵌套对象的反序列化触发链条。这意味着传统的输入类型校验与接口参数绑定策略在此类反序列化缺陷面前全面失效。
绕过 SafeMode 与类加载器的机制剖析
攻击者构造包含特定 @type 的恶意 JSON 负载，触发 Fastjson 的类型解析例程。在 Spring Boot 可执行 fat-JAR 环境中，Fastjson 将 @type 指向的资源转化为类资源查找逻辑，进而从嵌套的 fat-JAR 结构中提取攻击者可控的字节码。
资源中包含的 @JSONType 注解被解析器误认为是安全信任标记，顺理成章地绕过了类型安全检查并完成动态类加载。在 JDK 11、17、21 等较新的运行时环境中，攻击路径甚至可以通过下载远程 JAR 文件并借助 Linux 系统的 /proc/self/fd 文件描述符完成挂载引用。
测试数据显示，标准的 WAR 包部署模式以及普通的非 fat-JAR 环境在此次漏洞中未受影响。这说明现代 Java 应用打包范式与底层类加载机制的深度绑定，正在成为反序列化安全领域中难以防御的全新攻击面。 开发者往往关注高层代码逻辑，却忽视了构筑在复杂打包格式之上的隐蔽加载链条。
在野攻击迅速蔓延：金融与医疗行业首当其冲
威胁情报机构 ThreatBook 在 7 月 22 日捕获到了首批在野利用数据，并在 Spring Boot fat-JAR 与 JDK 8 的组合环境中复现了完整的远程代码执行。相比之下，基于嵌入式 Tomcat 的传统测试环境仅能触发远程 JAR 调取或 SSRF 行为。
Imperva 的安全监测报告显示，攻击活动迅速覆盖了金融服务、医疗保健、零售以及企业 IT 服务等多个关键领域。攻击流量主要来自北美地区以及新加坡和加拿大，其中大量请求伪装成标准浏览器行为以规避基础防护规则。
监控数据指出，约 30% 的攻击流量由基于 Ruby 和 Go 语言编写的自动化脚本发起。这说明黑产团伙已将漏洞快速武器化并集成为自动化扫描工具，大幅降低了大规模入侵的技术门槛。
CISA 在 7 月 23 日的评估中暂时未将该漏洞列入已知被利用漏洞目录（KEV），然而实际监测到的攻击流量攀升表明企业安全团队的应急处置窗口期极其紧迫。任何暴露在公网上的 Java 服务都可能迅速成为黑客扫描的靶场。
零补丁困境下的临时防御与迁移路线
由于 1.x 分支处于终止维护状态且暂无官方补丁，企业运维团队需要立刻采取主动防御措施以阻断攻击路径。最直接的应对手段是全局开启 SafeMode 机制。
运维人员可以通过添加 JVM 参数 -Dfastjson.parser.safeMode=true，或者在应用启动阶段执行 ParserConfig.getGlobalInstance().setSafeMode(true)。此举将彻底禁用 AutoType 以及 @type 的解析功能，从根本上锁死类型注入入口。
另一个临时方案是切换至阿里巴巴释出的受限构建版本 com.alibaba:fastjson:1.2.83_noneautotype。长远来看，业务团队必须规划向 Fastjson2 的升级迁移。
Fastjson2 采用了白名单优先的防御架构与全新的类型解析设计，彻底隔离了基于 @type 的任意类实例化途径。虽然迁移过程需要付出一定的代码适配成本，但这是彻底消除遗留组件安全隐患的唯一路径。
退役组件的「数字废墟」警示
Fastjson 1.x 的漏洞危机展示了开源基础设施生命周期管理的严峻挑战。大量企业系统在依赖库停止维护后依然长期运行在生产环境中，形成了巨大的安全隐患。
当核心组件进入终末状态，单纯依靠修补黑名单或配置微调已难以为继。开源软件不会随着终结维护而自动停止风险发酵，相反，遗留代码会随时间推移演变成黑客入侵的破绽。
唯有建立持续的依赖项审计机制，并在官方停止维护前完成架构升级，才能确保应用安全不受突发漏洞的冲击。企业需要重新评估自身技术栈中的历史遗留组件，杜绝「能跑就不动」的侥幸心理。
参考链接：
- Alibaba Cloud 开发者社区安全公告
- Imperva 官方安全博客分析报告
- The Hacker News 漏洞跟踪报道
- ThreatBook 威胁情报中心复现报告
