fastjson CVE-2026-16723 的官方补丁其实已经发了：1.2.84，只是没人告诉你

xiaoqiMikko
42 阅读4分钟

如果你这两周在处理 fastjson 的 CVE-2026-16723，大概率看到过这句话：

fastjson 1.x 已经 EOL，官方不会再发补丁，唯一出路是迁移到 fastjson2。

这句话在 2026 年 7 月 29 日之后就不成立了。

阿里在那天发布了 fastjson 1.2.84，修复了这个漏洞。但它是静默发布的 —— release 标题只写了「1.2.84版本发布」，全文没提一个「安全」字，所以安全媒体、漏洞库、扫描器全都没跟上，至今仍在说「无补丁」。

我是在给自己写的排查工具做复测时撞见的，顺手核实了一遍，写出来给还在赶工的人省点事。

先看证据，别信我

这类事不能靠转述，下面每条都可以自己点进去看：

证据链接
Maven 中央仓库有 com.alibaba:fastjson:1.2.84，jar 上传时间 2026-07-29repo1.maven.org/maven2/com/…
GitHub release 1.2.84，发布于 2026-07-29T08:24:51Zgithub.com/alibaba/fas…
关键提交 fix: strengthen autoType type name validation and whitelist verification2026-07-29T07:02:55Z

再看一个细节：1.2.83 发布于 2022 年 5 月，此后 1.x 分支四年没有任何提交。 1.2.84 是为这个漏洞专门破例发的版本。

为什么全网都没跟上

对比两个 release 的标题：

版本release 标题
1.2.83fastjson 1.2.83版本发布**（安全修复）**
1.2.84fastjson 1.2.84版本发布

1.2.83 那次明确标了「安全修复」，1.2.84 这次什么都没标。

漏洞库和媒体大多靠 release 标题、CVE 公告、官方博客这几个信号联动，静默发布刚好从这几个信号的缝里漏了过去。CVE 公告是 7 月 21 日，补丁是 7 月 29 日，而绝大多数报道停在 7 月下旬——在补丁之前。

顺带说一个更麻烦的事：Dependabot 可能根本没提醒你

GitHub 安全公告 GHSA-crf3-v9rr-v7hj 对应这个 CVE，但它的 affected 字段目前是空数组 —— 也就是说它没有关联任何具体的包和版本范围。

后果是：Dependabot 不会因为这个 CVE 对任何人告警。

所以别把「我的仓库没告警」当成安全。这个 CVE 目前需要你主动排查。

官方给的处置（原文顺序）

  1. 升级到 fastjson 1.2.84 ← 成本最低，同分支小版本，通常不用改代码
  2. 启用 SafeMode：-Dfastjson.parser.safeMode=true
  3. 使用 noneautotype 构建变体

1.2.84 的修法是：在 ParserConfig.checkAutoType 里拒绝含 URL 特殊字符（: / !）的类名。

另外两条容易踩的坑：

  • fastjson2 不受这个 CVE 影响。官方 advisory 原文写的是「All fastjson2 versions」不受影响。所以如果你已经在用 fastjson2，这个 CVE 不用管（但仍建议保持在较新版本）。
  • 指定目标类不是缓解措施。官方明确说了，攻击者可以把 payload 嵌套进 Object / Map 类型的字段里绕过。

触发条件（先确认自己中不中招）

官方给的条件是：

  • fastjson 版本在 1.2.68 ~ 1.2.83 之间
  • 默认配置（AutoType OFF、SafeMode OFF）—— 也就是说你什么都没开也会中
  • Spring Boot 可执行 fat-jar 部署
  • JDK 8 / 11 / 17 / 21，Spring Boot 2.x / 3.x / 4.x

注意第三条。这也是排查最麻烦的地方 ——

最难的部分：你可能不知道自己在用 fastjson

fastjson 很少是主动引入的，它通常是传递依赖，被某个 SDK 捎带进来。而 mvn dependency:tree 在两种情况下会失效：

  1. 生产机上只有一个打好的 fat-jar，没有源码和 pom
  2. fastjson 被 shade 进了某个厂商 SDK 内部，依赖树上根本不出现

我为此写了个小工具 fastjson-check，做的就是这一件事：

  • 递归展开 Spring Boot fat-JAR（在内存里，不解压落地）
  • 溯源到具体的嵌套路径，包括被 shade 进宿主 jar 的情况
  • 按版本给出判定和处置建议

单个 jar，23KB，零运行时依赖，Java 8 起可用，完全离线不外传任何数据。

java -jar fastjson-check.jar ./myapp.jar     # 扫一个 jar
java -jar fastjson-check.jar /opt/apps       # 扫一个目录
java -jar fastjson-check.jar /opt/apps --json

输出长这样：

[CRITICAL] fastjson 1.2.83
  位置　　：myapp.jar!/BOOT-INF/lib/fastjson-1.2.83.jar
  版本来源：pom.properties
  结论　　：命中 CVE-2026-16723（CVSS 9.0 远程代码执行），默认配置即可利用
  处置　　：①（推荐，改动最小）升级至 fastjson 1.2.84 ...

[OK] fastjson 1.2.84
  结论　　：已包含 CVE-2026-16723 的官方修复（1.2.84 起）

仓库和下载：github.com/xiaoqiMikko…

顺便自曝一个 bug：这个工具的第一版把 CVE 上界写死成 1.2.83，还在注释里断言「1.2.83 是 1.x 的最终版本」—— 结果就是把已经修好的 1.2.84 报成了高危，还建议人家去做 fastjson2 大版本迁移。上面这个发现就是在修这个 bug 的过程中撞出来的。v0.2.0 已修正，如果你下过 v0.1.0，请换 v0.2.0。

一句话总结

补丁存在，叫 1.2.84，2026-07-29 发布，官方没吭声。

如果你正因为「无补丁」而在排 fastjson2 的迁移工期，可以先停一下重新评估 —— 升个小版本可能就够了。

avatar
文章
阅读
粉丝