文章总结： Fastjson1.2.68至1.2.83版本在特定SpringBootfat-JAR部署条件下存在远程代码执行风险，厂商已发布安全公告。企业需根据实际部署形态、版本和入口可达性评估风险，采取迁移至Fastjson2、开启SafeMode或隔离入口等处置路径。核心是建立可审计的运行证据和决策清单，而非仅追求升级状态表。 综合评分： 91 文章分类： 漏洞分析,应急响应,安全工具,安全建设,解决方案

Fastjson 1.x 没有补丁可等：企业该升级、隔离还是替换

原创

tcode tcode

字节脉搏实验室

2026年7月27日 10:07 北京

在小说阅读器读本章

去阅读

    7 月 21 日，Alibaba 在 Fastjson2 项目发布安全公告：Fastjson 1.2.68 至 1.2.83 在特定 Spring Boot 可执行 fat-JAR 部署条件下存在远程代码执行风险，Fastjson2 不受同一问题影响。公告给出的严重等级为 Critical，并强调风险可以出现在 AutoType 未开启、SafeMode 仍为默认关闭的环境。

    随后，ThreatBook 表示捕获到在野利用活动；Imperva 也报告针对多个行业的探测和利用请求。公开报告没有给出完整攻击数量、具名受害者或所有请求成功执行的证据。它们足以把优先级抬高，却不能被扩写成“已发生大规模入侵”。

    先别问有没有 Fastjson，先问生产环境怎么运行

    漏洞公告列出的条件很具体：使用 Fastjson 1.2.68 至 1.2.83，应用以 Spring Boot 可执行 fat-JAR 运行，外部可控 JSON 能到达相关解析路径，SafeMode 没有开启。普通非 fat-JAR、通用 uber-JAR，以及常规 WAR 部署不在厂商列出的同一受影响条件中。

    这意味着一份只列组件名和版本的扫描报告不够。相同依赖版本，因打包方式、入口暴露和运行参数不同，优先级可能完全不同。企业需要把软件成分、构建产物、启动方式和真实流量放在一起判断。

    第一步是确认实际装进产物的版本。不能只看代码仓库里的依赖声明，因为 Fastjson 可能由其他组件传递引入，也可能在构建时被锁定为旧版本。研发团队应输出依赖树，同时检查最终 fat-JAR 内部，确保“计划使用的版本”和“生产运行的版本”一致。

    第二步是确认真正的部署形态。容器镜像标签、服务名称和 Spring Boot 版本都不能替代检查启动命令与应用包结构。尤其要找出那些以可执行 fat-JAR 直接启动、又接收公网或合作方 JSON 请求的服务。

    第三步是确认入口是否可达。不能因为接口需要业务参数或绑定到固定对象就自动判定安全。厂商明确提醒，固定对象中仍可能包含 Object 或 Map 类型字段。这里无需复现攻击，只需让研发列出外部输入到 JSON 解析器的真实调用关系。

    三种处置路径，不能混成一个“已缓解”

    路径一：迁移到 Fastjson2 或替代库。这是厂商给出的长期方向，适用于核心系统、互联网暴露接口和仍在持续迭代的业务。迁移不是简单替换坐标，需要验证字段兼容、日期与数字处理、序列化差异、异常处理及性能。正确顺序是先建立回归样本，再替换依赖，最后对生产流量做灰度观察。

    路径二：短期开启 SafeMode。厂商把 SafeMode 视为阻断相关类型处理的缓解措施，也提供受限制的 1.2.83_noneautotype 构建。它适合无法立即迁移、但可以快速验证业务兼容性的系统。启用后必须检查启动参数确实进入生产进程，并回归依赖多态反序列化的旧业务；仅在配置中心写入参数、却没有验证 JVM 实际参数，不算完成。

    路径三：先隔离入口。对已停维、难以改造或供应商封装的系统，应先限制外部可达性，只允许明确的上游调用，并监控异常出站连接和子进程行为。隔离能降低暴露面，但不是修复。只要不可信 JSON 仍能到达解析路径，就不能把风险状态写成关闭。

    管理者需要的是一张决策清单

    第一优先级应给“受影响版本 + fat-JAR + 外部可达 + 关键数据或高权限运行账户”同时成立的服务。这类系统不应等待下一次常规维护窗口。

    第二优先级是内部服务和合作方接口。内部并不等于可信，尤其当调用方数量多、账号边界弱或服务位于共享网络。可以先收紧来源，再安排迁移，但要记录临时措施的负责人和失效日期。

    第三优先级是扫描发现依赖、却尚未证明生产可达的系统。它们不应该被忽略，也不应该与暴露服务抢同一批应急资源。给研发一个明确时限，补齐产物、启动参数和入口证据，再调整等级。

    对于采购软件或由供应商封装的系统，业务团队通常没有权限直接替换依赖。这时应向供应商索取四项书面证据：产品是否包含受影响版本、实际打包和启动方式、已经验证的临时缓解措施、正式修复时间。供应商只回复“已关注”或只给一个计划版本号，不足以降低风险。无法及时提供运行证据的产品，应先通过访问控制、独立网络区和出站限制降低暴露，并把替代方案纳入业务连续性评估。

    应急检查按这个顺序执行

    1. 建清单：列出直接和传递依赖、最终产物版本、部署类型、JDK 与 Spring Boot 版本、服务所有者。

    2. 排可达：确认哪些接口接收不可信 JSON，记录公网、合作方、内部三类来源，不用“内网”一词代替边界说明。

    3. 先止血：对高风险服务开启并验证 SafeMode，或暂时限制入口；变更前后各留一份配置证据。

    4. 做迁移：优先升级到 Fastjson2 或经评估的替代库，完成回归、灰度和回退计划。

    5. 查异常：结合 Web、应用和主机日志检查异常类型字段、未知出站、Java 子进程、文件变化及 Web 目录异常。发现入侵迹象时转入事件响应，不再把它当普通补丁任务。

信息边界

    已确认的是厂商公告中的影响条件与缓解方向，以及安全厂商观察到利用请求。尚未公开确认的是成功入侵规模和具名受害组织。7 月 25 日的公开核对显示，该漏洞当时不在 CISA KEV 目录中；不在目录不代表没有风险，也不能反过来证明所有报告都等同于成功利用。

    本文的判断是：这次工作的核心不是追求一张“全部已升级”的表，而是让每个生产服务都有可审计的运行证据和处置决定。

结语

    Fastjson 1.x 事件暴露的是企业漏洞管理里最常见的断层：扫描器知道组件版本，研发知道代码，平台团队知道容器，只有很少的人能把它们拼成生产风险。

    没有直接补丁可等时，决策质量比修复口号更重要。先找真实产物，再判入口，随后止血和迁移，最后用日志确认有没有越过“漏洞”进入“事件”。这才是一条可以关单的路径。

参考来源

• Alibaba Fastjson2 Wiki：Security Advisory: RCE in fastjson 1.2.68-1.2.83（2026-07-21，页面未标明时区）

• Imperva：Customers Protected Against CVE-2026-16723（2026-07-24 18:16:29 UTC；北京时间 2026-07-25 02:16:29）

• The Hacker News：Fastjson 1.x RCE Vulnerability Targeted in Attacks（2026-07-25 18:22:43 +05:30；北京时间 20:52:43）

• NVD：CVE-2026-16723

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：字节脉搏实验室 tcode tcode《Fastjson 1.x 没有补丁可等：企业该升级、隔离还是替换》