⚠️ 2026-08-04 重要更正:官方补丁已经发布了本文最初写于 2026-08-03,文中「官方不会发布补丁、1.x 已停止维护」的说法是错的,在此更正。阿里已于 2026-07-29 发布 fastjson 1.2.84,修复了 CVE-2026-16723。之所以几乎没人知道,是因为这是一次静默发布—— 1.2.83 的 release 标题标注了「(安全修复)」,而 1.2.84 只写「1.2.84版本发布」,全文未提安全,所以安全媒体和扫描器都没跟进。可自行核验:Maven 中央仓库 https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.84/ ,jar 上传时间 2026-07-29GitHub release https://github.com/alibaba/fastjson/releases/tag/1.2.84 ,发布于 2026-07-29T08:24:51Z关键提交:fix: strengthen autoType type name validation and whitelist verification对你的实际影响:升级到 1.2.84 是同分支小版本升级,通常无需改代码,不必被迫立刻做 fastjson2 的大版本迁移。详细说明另见新文:fastjson 1.2.84 修复了吗?CVE-2026-16723 官方补丁核实与排查方法先给结论如果你只有 3 分钟直接看这段影响范围fastjson 1.2.68 ~ 1.2.83CVSS 9.0默认配置即可远程代码执行不需要开 AutoType。官方已出补丁:1.2.84(2026-07-29 静默发布,详见文首更正)。升个小版本通常就够,不必被迫做 fastjson2 大版本迁移。mvn dependency:tree查不全。两种情况漏检①手上只有打好的 fat-JAR没有构建环境②fastjson 被 shade 进了某个 SDK 内部依赖树上根本没这个节点。迁到 fastjson2 也不一定安全fastjson2 ≤ 2.0.62 自身有 RCE安全版本是 2.0.63。快速自查命令离线不联网不上传任何数据java-jarfastjson-check.jar ./myapp.jarjava-jarfastjson-check.jar /opt/apps下面展开说为什么依赖树查不全以及这两种漏检情况具体长什么样。2026 年 7 月 21 日fastjson 公布了 CVE-2026-16723CVSS 9.0远程代码执行默认配置即可利用——不需要开启 AutoType不需要 classpath 上有特定 gadget不需要认证。影响范围是 fastjson1.2.68 ~ 1.2.83。这次和以往几次 AutoType 系列漏洞有个本质区别官方不会发布补丁。fastjson 1.x 已经停止维护,GitHub 仓库已归档。⚠️ 上述说法已过时:阿里已于 2026-07-29 发布fastjson 1.2.84修复本漏洞。因为是静默发布(release 标题未提安全),当时全网都还在说「无补丁」。也就是说不存在升个小版本就完事这条路。要么迁移要么长期带病运行。公告后数日就出现了在野利用主要目标是Spring Boot fat-JAR部署。真正的难点不是修是找如果你的pom.xml里明明白白写着 fastjson那这篇文章对你没什么用——你已经知道自己中招了直接去迁移就行。问题在于大多数团队的 pom.xml 里根本没有 fastjson。fastjson 极少被主动引入它几乎都是传递依赖——被各种 SDK 捎带进来的。国内生态里尤其严重支付、短信、对象存储、消息推送、地图、各种开放平台的 Java SDK很多都在内部用 fastjson 做 JSON 序列化。于是就出现了一个尴尬局面你没装它但你在用它。而你不知道。两个mvn dependency:tree的盲区排查的第一反应当然是跑依赖树mvn dependency:tree|grepfastjson这在大部分情况下够用。但有两种情况它无能为力而这两种恰恰是应急场景里最常见的。盲区一你手上只有一个打好的 fat-JAR线上应急的典型场景运维扔给你一个myapp.jar没有源码机器上没有 Maven甚至没有网。这时候dependency:tree是跑不了的——它需要构建环境和完整的 POM 依赖解析。有人会说那就unzip出来看。可以但 Spring Boot fat-JAR 的结构是BOOT-INF/lib/*.jar里面几十上百个 jar还可能有嵌套。手工翻一遍的成本很高而且容易漏。盲区二fastjson 被 shade 进了别的 jar 内部这个更隐蔽。有些 SDK 为了避免版本冲突会在打包时用maven-shade-plugin把 fastjson直接打进自己的 jar 里。结果就是依赖树上完全没有fastjson 这个节点但目标 jar 内部实实在在有com/alibaba/fastjson/JSON.class这段代码会被正常加载、正常执行、正常受漏洞影响我一开始也以为依赖树干净就等于没事。实际上依赖树干净只说明没有独立的 fastjson 依赖节点不说明 classpath 上没有 fastjson 的字节码。能被 JVM 加载的类才是攻击面。依赖树只是它的一个不完整投影。写了个工具专门查这两种情况针对上面两个盲区写了个小工具fastjson-check# 扫一个 jarSpring Boot fat-JAR 会自动逐层展开java-jarfastjson-check.jar ./myapp.jar# 扫一整个目录递归找所有 jar/warjava-jarfastjson-check.jar /opt/apps# 输出 JSON接流水线java-jarfastjson-check.jar /opt/apps--json输出长这样fastjson-check 0.1.0 —— fastjson 应急排查离线不外传任何数据 扫描目标myapp.jar 已展开归档3 个 发现 2 处 fastjson [CRITICAL] fastjson 1.2.83 位置 myapp.jar!/BOOT-INF/lib/fastjson-1.2.83.jar 版本来源pom.properties 场景 Spring Boot fat-JAR ← CVE-2026-16723 的主要在野利用场景 结论 :命中 CVE-2026-16723(CVSS 9.0 远程代码执行) 处置 :按成本从低到高:①(推荐)升级至 fastjson **1.2.84** —— 同分支小 版本升级,通常无需改代码;② 迁移至 fastjson2 2.0.63;③ 无法升级时 先启用 SafeMode 彻底关闭 AutoType 缓解。 [UNKNOWN] fastjson 版本未知 位置 myapp.jar!/BOOT-INF/lib/some-sdk-3.1.0.jar 版本来源未知 注意 疑似被 shade 进宿主 jar有 class 但无 Maven 元数据 mvn dependency:tree 查不到它 结论 无法确定 fastjson 版本 汇总CRITICAL 1 UNKNOWN 1注意第二条——那个some-sdk-3.1.0.jar把 fastjson 打进了自己内部依赖树上完全看不见。这正是它存在的理由。几个设计上的取舍零运行时依赖。一个排查工具不该再往目标环境里塞任何东西尤其不该塞 JSON 库——我们查的就是它。全程只用 JDK 自带的java.util.zip。编译目标 Java 8。企业环境里大量 JRE 还是 8打出来的 jar 要能直接丢到老机器上跑。完全离线。不联网、不上传任何数据。排查生产环境的包把路径和依赖清单发到第三方服务器上是不可接受的。内存内展开嵌套 jar。不往磁盘落任何临时文件。整个 jar23KB。一个容易踩的坑迁到 fastjson2 ≠ 安全官方给的迁移方向是 fastjson2。但要注意fastjson2 在 ≤ 2.0.62 时自身也有 RCE多态反序列化seeAlso 路径同样是默认配置可触发。所以「我们已经迁到 fastjson2 了」这句话本身不构成安全结论必须同时看版本号。安全版本是2.0.63 及以上。完整判定规则版本判定说明fastjson1.2.68 ~ 1.2.83 CRITICAL命中 CVE-2026-16723,升级至 1.2.84 即修复fastjson≥ 1.2.84 OK已包含 CVE-2026-16723 的官方修复fastjson 1.x 其他版本 HIGH不中本次 CVE,但有历史 AutoType RCE 系列漏洞fastjson2≤ 2.0.62 CRITICAL多态反序列化 RCE默认配置即可触发fastjson2≥ 2.0.63 OK当前推荐版本接 CI退出码设计成可以直接做门禁0 未发现需处理项1 发现 CRITICAL/HIGH2 用法错误java-jarfastjson-check.jar ./build/libs||echo发现高危依赖阻断发布它不是什么诚实说明边界免得误以为安全它不是通用 SCA 工具。只查 fastjson 一个库不查其他 CVE。要全面的依赖安全扫描请用 Snyk / OWASP Dependency-Check / Dependency-Track。改了包名的 relocate 打包检测不到。它靠com/alibaba/fastjson(2)/JSON.class这个路径识别如果某个库在 shade 时把包名 relocate 成了com.foo.shaded.fastjson就查不出来。它不判断可达性。发现依赖存在 ≠ 一定能被攻击是否真的可利用取决于有没有外部可控的 JSON 输入路径。但在应急阶段先把「有没有」查清楚是第一步。它不改你的代码。只报告不动手。获取方式工具是我写的Apache 2.0 开源已用 Maven 中央仓库的真实fastjson 1.2.62 / 1.2.83 和 fastjson2 2.0.62 / 2.0.63 验证过26 个单元测试。下载23KB单个 jar零依赖Java 8 可跑https://github.com/xiaoqiMikko/fastjson-check/releases如果打不开 GitHub命令行直接拉curl-LOhttps://github.com/xiaoqiMikko/fastjson-check/releases/download/v0.1.0/fastjson-check.jar用法java-jarfastjson-check.jarjar文件或目录java-jarfastjson-check.jar目标--json# JSON 输出接流水线java-jarfastjson-check.jar目标--utf8# Windows 控制台中文乱码时加这个退出码0未发现需处理项 /1发现 CRITICAL 或 HIGH /2用法错误可直接做 CI 门禁。源码https://github.com/xiaoqiMikko/fastjson-check发现误报或漏报请在 GitHub 提 issue。安全工具最怕的就是让人误以为安全任何一条误判我都想知道。