Fastjson 官方发布安全公告，披露 Fastjson 1.2.68 至 1.2.83 版本存在严重远程代码执行漏洞。该漏洞在特定部署环境下，无需开启 AutoType，也不依赖传统反序列化 Gadget 链，攻击者便可能通过构造恶意 JSON 数据，在目标服务器上执行任意代码。官方将该漏洞严重等级评定为 Critical。截至 2026 年 7 月 24 日，该漏洞尚未分配公开 CVE 编号，但相关技术细节和验证结果已经公开，使用 Fastjson 1.x 的企业应尽快完成资产核查和风险处置。

一、AutoType 已关闭，为什么仍然可能被攻击？

过去，Fastjson 反序列化漏洞通常与 AutoType 功能有关。许多企业认为，只要保持 AutoType 关闭，就能避免攻击者指定任意 Java 类型。此次漏洞打破了这一常见认知。根据官方公告，漏洞存在于 Fastjson 1.2.68 至 1.2.83 版本的类型检查和资源加载逻辑中。在 Fastjson 处理 JSON 数据中的 @type 字段时，部分用户可控内容可能进入资源查找和类加载流程。攻击者可以利用这一逻辑，引导应用访问外部恶意资源，并在符合条件的 Spring Boot 环境中完成从资源加载到远程代码执行的攻击过程。

结论：即使应用使用 Fastjson 默认配置，AutoType 处于关闭状态，只要 SafeMode 没有开启，依然可能存在风险。安全研究将其描述为一条从 SSRF、外部资源加载进一步发展为 RCE 的利用链。

二、哪些系统可能受到影响？

此次漏洞并非影响 Fastjson 1.x 全部版本。目前官方确认的受影响范围为：

  • Fastjson 版本处于 1.2.68 至 1.2.83 之间；
  • 应用未开启 SafeMode；
  • 应用采用 Spring Boot 可执行 fat jar 方式部署，通常通过 java -jar xxx.jar 启动；
  • 应用存在攻击者可以控制或影响的 JSON 输入；
  • 应用调用了 JSON.parse、JSON.parseObject(String) 或相关 JSON 解析接口。

官方已在 Spring Boot 2.x、3.x 和 4.x，以及 JDK 8、11、17 和 21 环境中完成端到端验证。即使开发人员在解析时指定了目标 DTO 类型，也不能简单认定风险已经消除，因为攻击者仍可能通过 DTO 中的 Object 或 Map 类型字段嵌套恶意数据。

三、哪些情况目前不受影响？

  • Fastjson 2 所有版本；
  • Fastjson 1.x 已经开启 SafeMode；
  • 使用 1.2.83_noneautotype 等移除相关代码的构建版本；
  • 不满足漏洞触发条件的非 fat jar 部署环境；
  • Fastjson 1.2.60 及以下版本（相关漏洞代码路径尚不存在）。

需要注意的是，不受本次漏洞影响并不意味着这些版本不存在其他历史安全问题。较早的 Fastjson 版本可能仍包含其他反序列化漏洞和绕过风险，因此不建议将降级到旧版本作为长期解决方案。

四、企业应该如何完成紧急整改？

企业首先需要确认应用是否实际引用了 Fastjson，并识别具体版本。排查范围不应只覆盖业务代码，还应包括第三方 SDK、中间件组件、历史遗留系统和间接依赖。

在无法立即完成版本迁移的情况下，可以优先开启 SafeMode：

  • JVM 启动参数：-Dfastjson.parser.safeMode=true
  • 程序初始化阶段：ParserConfig.getGlobalInstance().setSafeMode(true);

企业还可以临时切换至 Fastjson 的 noneautotype 构建版本。不过，从长期安全治理角度看，官方建议迁移至 Fastjson 2.x。Fastjson 2 已经从架构上移除了此次漏洞涉及的资源探测和信任绕过机制，默认配置不受本次漏洞影响。升级过程中，研发团队仍需对序列化结果、日期格式、多态类型、历史接口兼容性和上下游数据交换进行完整回归测试。

五、云新 CloudSino 已完成相关能力更新

针对本次 Fastjson 严重远程代码执行风险，云新 CloudSino 已更新相关安全识别与风险提示能力，帮助客户更快定位可能受影响的服务器、应用环境和组件版本。依托统一资产管理、设备自动发现、配置采集和运维数据关联能力，云新平台可以协助运维团队梳理服务器与业务系统之间的关系，减少依赖人工登记和跨系统查询带来的遗漏。

对于已识别的风险设备，管理人员可以结合资产位置、设备负责人、业务关联关系和运行状态制定整改优先级，优先处理承载核心业务、对外提供接口或位于高风险网络区域的系统。同时，云新平台可以持续记录设备配置和资产变化，为漏洞整改后的复核、审计和追踪提供数据依据。

结语：让漏洞治理跑在攻击前面

Fastjson 此次漏洞再次说明，开源组件风险已经成为企业基础设施运维中不可忽视的一部分。安全管理不能只依赖漏洞发生后的人工通知，还需要建立覆盖资产发现、版本识别、影响分析、整改跟踪和持续验证的闭环机制。当新的高危漏洞出现时，企业越早看清资产和业务关系，就越能减少风险暴露时间，避免一次组件漏洞演变为影响核心业务的安全事件。

配图1