⚠️ 2026-08-14 更正:「静默发布」这个说法是错的本文原写「1.2.84 的 release 标题只写了『1.2.84版本发布』,全文没提一个『安全』字」——后半句是错的,而且是我当初没读正文就写下的。实测:1.2.84 的 release 正文有完整的Security Fixes章节,逐条列了四项 AutoType 加固,并且从发布当天(2026-07-29)就是这样(Wayback 存档20260729094935可查)。对的只有半句:它的标题确实没有像 1.2.83 那样标注「(安全修复)」。「为什么这个补丁在中文圈几乎没被提起」,我现在没有答案—— 原来给出的解释站不住,就不拿另一个猜测顶上。本文核心结论不变,且 2026-08-14 又独立复核过:该公告至今没有修复版本字段(first_patched_version仍是null);按包查询 fastjson 返回的修复版是1.2.31 / 1.2.83 / 1.12.0 / 1.2.48,里面没有 1.2.84。补丁确实存在,但你的扫描器不会告诉你升到它。⚠️ 2026-08-12 更正:GitHub 已补上包信息,Dependabot 现在会告警了本文写于 2026-08-04。当时GHSA-crf3-v9rr-v7hj的affected是空数组,Dependabot 对任何人都不告警 —— 下文「Dependabot」那一节就是基于这个事实写的。2026-08-07 GitHub 补上了:该公告现在关联com.alibaba:fastjson,受影响区间 1.2.68, 1.2.83。所以那一节已经过时,正文已同步改写(改,不删)。但本文的核心结论没有变,反而更清楚了:该公告至今没有修复版本字段(first_patched_version仍是null)。也就是说,Dependabot 现在会告诉你「你中招了」,却仍然不会告诉你升到 1.2.84。「补丁存在,只是没人告诉你」这件事本身没变。如果你这两周在处理 fastjson 的 CVE-2026-16723大概率看到过这句话fastjson 1.x 已经 EOL官方不会再发补丁唯一出路是迁移到 fastjson2。这句话在 2026 年 7 月 29 日之后就不成立了。阿里在那天发布了fastjson 1.2.84修复了这个漏洞。它的 release标题只写了「1.2.84版本发布」没有像 1.2.83 那样标注「安全修复」——不过正文里是有完整Security Fixes章节的见文首 08-14 更正。安全媒体、漏洞库、扫描器至今仍有不少在说「无补丁」为什么会这样我没有查清。我是在给自己写的排查工具做复测时撞见的顺手核实了一遍写出来给还在赶工的人省点事。先看证据别信我这类事不能靠转述下面每条都可以自己点进去看证据链接Maven 中央仓库有com.alibaba:fastjson:1.2.84jar 上传时间 2026-07-29https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.84/GitHub release1.2.84发布于 2026-07-29T08:24:51Zhttps://github.com/alibaba/fastjson/releases/tag/1.2.84关键提交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 的标题没有标——但它的正文写了Security Fixes。CVE 公告是 7 月 21 日补丁是 7 月 29 日而绝大多数报道停在 7 月下旬——在补丁之前。至于补丁发出之后为什么仍然没有跟进我没有查清这里不编一个原因。顺带说一个更麻烦的事Dependabot 就算提醒你也不会告诉你升到哪GitHub 安全公告GHSA-crf3-v9rr-v7hj对应这个 CVE。本文发布时它的affected字段是空数组不关联任何具体的包和版本范围;2026-08-07 GitHub 补上了—— 现在关联com.alibaba:fastjson受影响区间 1.2.68, 1.2.83。但它的修复版本字段(first_patched_version)至今仍是null。所以后果变成了:Dependabot 现在会告警,却不会告诉你该升到哪个版本—— 而答案是 1.2.84。所以:08-07 之前,别把「我的仓库没告警」当成安全;08-07 之后,也别以为收到告警就知道该怎么办。这个 CVE 仍然需要你自己确认版本。官方给的处置原文顺序升级到 fastjson 1.2.84← 成本最低同分支小版本通常不用改代码启用 SafeMode-Dfastjson.parser.safeModetrue使用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 / 21Spring Boot 2.x / 3.x / 4.x注意第三条。这也是排查最麻烦的地方 ——最难的部分你可能不知道自己在用 fastjsonfastjson 很少是主动引入的它通常是传递依赖被某个 SDK 捎带进来。而mvn dependency:tree在两种情况下会失效生产机上只有一个打好的 fat-jar没有源码和 pomfastjson 被shade 进了某个厂商 SDK 内部依赖树上根本不出现我为此写了个小工具fastjson-check做的就是这一件事递归展开 Spring Boot fat-JAR在内存里不解压落地溯源到具体的嵌套路径包括被 shade 进宿主 jar 的情况按版本给出判定和处置建议单个 jar23KB零运行时依赖Java 8 起可用完全离线不外传任何数据。java-jarfastjson-check.jar ./myapp.jar# 扫一个 jarjava-jarfastjson-check.jar /opt/apps# 扫一个目录java-jarfastjson-check.jar /opt/apps--json输出长这样[CRITICAL] fastjson 1.2.83 位置 myapp.jar!/BOOT-INF/lib/fastjson-1.2.83.jar 版本来源pom.properties 结论 命中 CVE-2026-16723CVSS 9.0 远程代码执行默认配置即可利用 处置 ①推荐改动最小升级至 fastjson 1.2.84 ... [OK] fastjson 1.2.84 结论 已包含 CVE-2026-16723 的官方修复1.2.84 起仓库和下载https://github.com/xiaoqiMikko/fastjson-check顺便自曝一个 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.842026-07-29 发布官方没吭声。如果你正因为「无补丁」而在排 fastjson2 的迁移工期可以先停一下重新评估 —— 升个小版本可能就够了。