大家好我是程序员天天困。2026 年 7 月Fastjson 1.x 又爆远程代码执行洞JSON工具类选型这事又被拎到台面上。按阿里官方安全公告致谢发现并负责任披露的是 FearsOff 研究员 Kirill Firsov——影响面覆盖1.2.681.2.83连当年被当成“安全终点”的 1.2.83 也没能幸免。更扎心的是默认解析入口就能走不依赖第三方 gadgetSafeMode 没开就中招。还只看谁解析更快真的会踩雷。洞一公开国内厂商也很快跟上。奇安信 CERT 在2026-07-20发了风险通告腾讯云安全通告页落款是2026-07-23同样点名 CVE-2026-16723并强调这是gadget-free不靠 classpath 里额外危险类的反序列化 RCE下面我会把这次洞、历史坑以及 Jackson / Gson / Hutool 怎么选一次讲清楚。点个收藏我们开始。一、这次 Fastjson 漏洞 CVE-2026-16723 到底怎么回事以 2026 年 7 月底为准还在用 Fastjson 1.2.681.2.83 解析不可信 JSON 的项目应优先当事故处理而不是当“听说有个洞”。时间线按一手源、按日期排一下更清楚1FearsOff / Kirill Firsov 发现并负责任披露阿里官方公告致谢2奇安信 CERT 风险通告公开时间2026-07-203阿里 fastjson2 官方安全公告 标注发布日2026-07-21后于 07-29 更新4腾讯云安全通告 页落款2026-07-23别被二手文章里的“统一 7 月 20 日”带偏——以各家页面自己写的日期为准。阿里官方公告里写得很直白CVECVE-2026-16723影响版本官方fastjson1.2.681.2.83含 1.x 最后一版 1.2.83触发条件默认配置即可AutoType 关、SafeMode 关不需要classpath 上再塞第三方 gadget常见部署前置目标跑在Spring Boot 可执行 fat-jarjava -jar xxx.jar入口JSON.parse、JSON.parseObject(String)、甚至JSON.parseObject(String, Class)都可达——指定 DTO 也不是银弹Object/Map 字段里照样能嵌 payload腾讯云通告也把核心特征写死了无需依赖特定第三方类库即可打到 RCE未开 SafeMode 的 1.x 实例在其通告范围内。有个细节要注意腾讯云通告写的影响版本是1.2.371.2.83比阿里官方 wiki 的1.2.681.2.83更宽做版本自查时我建议以阿里官方安全公告为准同时把云厂商通告当风险信号别互相打架。说人话以前很多团队以为「AutoType 关掉就安全了」。这次官方确认默认关掉也能走通危险路径。更扎心的是1.2.83 曾是 CVE-2022-25845 的修复终点很多人停在这里就再也没动过。官方给出的 P0 动作也很清楚公告更新于 2026-07-291升到fastjson 1.2.842026-07-29 安全修复版2或立刻开SafeMode-Dfastjson.parser.safeModetrue/ParserConfig.getGlobalInstance().setSafeMode(true)3或迁到fastjson2此 CVE 从架构上不受影响另外公告末尾提醒fastjson2 还有独立的 AutoType 加固问题请升到2.0.63 及以上。别把「不受这个 CVE 影响」理解成「永远不用升级」。发现与披露致谢见同一份官方 wikiKirill Firsov / FearsOff。补充一句时效腾讯云通告发出时还写“官方暂未发 1.x 补丁、建议迁 2.x / 开 SafeMode”到2026-07-29阿里已经放出1.2.84。读旧通告时记得对一下后续补丁。二、Fastjson 历史里几次真正伤人的洞Fastjson 的安全史本质上是一条 AutoType 攻防拉锯线不是偶发的“手滑 bug”。AutoType自动类型反序列化时允许 JSON 里用type指定具体 Java 类库再去加载并实例化。类比快递单上你自己填“收件人是谁”快递员按你写的门牌送——写错还是小事写成危险地址就麻烦了。几条经得起一手源核对的节点1CVE-2017-18349Fastjson1.2.25 之前parseObject可被构造请求打到远程代码执行NVD 给出 CVSS 3.x9.8。NVDCVE-2017-183492CVE-2022-25845Fastjson1.2.83 之前默认关闭 AutoType 仍可被绕过反序列化不可信数据可打远程服务器。阿里云漏洞库 AVD-2022-25845披露 2022-06-1131.2.83 → 1.2.842022 年大家把 1.2.83 当终点2026 年 7 月又证明终点会移动。仓库若早已归档、业务又停在 1.x风险窗口会特别长。中间还有一串 AutoType / JNDI 相关的补丁版本例如社区常提的 1.2.48 附近加固细节不必背全记住一句就够只要你还在解析外部不可信 JSONFastjson 1.x 就不该是“装完忘”的依赖。三、Spring Boot 里常见 JSON 工具怎么分工在 Spring Boot 项目里HTTP 出入参的默认选手通常是 Jackson不是 Fastjson。JacksonJava 里最常见的 JSON 序列化/反序列化库Spring MVC / Spring Boot 默认集成。类比厨房里自带的那把主厨刀日常切什么都先找它。GsonGoogle 出品的 JSON 库API 顺手注解体系清晰。类比外出野餐带的折叠刀——好用、好带但不一定是你后厨主力。Hutool JSONUtilHutool 这个 Java 工具全家桶里的 JSON 快捷方法偏“写业务辅助代码时顺手转一下”。类比工具柜里的多功能钳拧螺丝、剪线都行但别拿它当手术刀接公网不可信流量。可能有人会问我记得还有个跟 Hutool 很像的“啥都能干”的库常见是Guava或Jodd。Guava 强在集合、缓存、并发工具本身几乎不当 JSON 引擎团队里往往和 Gson 搭配Jodd 也有 JSON 模块但国内 Spring Boot 项目里出现频率通常低于 Hutool。选型别把“工具全家桶”和“专用 JSON 引擎”混成一件事。Spring Boot 默认链路大致是RequestBody/ResponseBody→HttpMessageConverter→Jackson的ObjectMapper。你在业务里再引一套 Fastjson等于同一项目两套规则——日期格式、空值、多态、异常行为都可能对不上。// 示例业务里自己再套一层时先想清楚是不是真需要第二套引擎ObjectMappermappernewObjectMapper();UserDTOusermapper.readValue(json,UserDTO.class);Stringoutmapper.writeValueAsString(user);四、Fastjson、Jackson、Gson、Hutool 怎么比JSON工具类选型时我优先看“是否解析不可信输入”其次才看 API 爽不爽、跑分漂不漂亮。维度JacksonFastjson / Fastjson2GsonHutool JSONUtilSpring Boot 契合默认集成最省心需额外接入可接非默认非 HTTP 层默认方案安全口碑接公网相对稳仍要控多态配置1.x 历史包袱重2.x 需跟版本通常更克制取决于你怎么用、解析什么API 手感注解强、可定制深静态方法很香学习曲线平工具类超顺手更适合Web API、复杂对象图性能敏感且能跟版本治理简单 DTO、工具脚本内部工具代码、快速转换社区里 JMH / 批量对比文章不少结论经常是小对象谁都差不多大对象、批量场景 Fastjson2 / Jackson 常更亮眼Gson、Hutool 更偏易用。跑分能参考但不能替代安全与生态判断——尤其你刚看完 CVE-2026-16723。你可能会想那 Fastjson 和 Jackson 对比性能党是不是必须上 Fastjson我更建议——先确认你有没有可感知的性能瓶颈。很多接口慢在 DB、远程调用、日志不在 JSON。真要压榨解析再评估 Fastjson2并且把版本升级、SafeMode/白名单策略写进规范别靠口头约定。五、我认为项目里该怎么选以 2026 年 8 月为准我的默认立场新 Spring Boot 项目 HTTP 层用 Jackson遗留 Fastjson 1.x 先止血再谈迁移。落地顺序我会这么排1新项目 / 主链路跟 Spring Boot用Jackson。日期、时区、未知字段、多态用注解和统一ObjectMapperBean 管起来。2已经在用 Fastjson 1.x立刻盘点版本。落在 1.2.681.2.83 且解析外部 JSON按官方建议升1.2.84或开 SafeMode中长期迁fastjson2≥2.0.63或干脆回到 Jackson。3Gson适合 SDK、小工具、对 Google 生态更熟的团队当第二套引擎可以别和 Jackson 在同一条 HTTP 链路上打架。4Hutool JSONUtil继续用在内部转换、测试代码、非不可信输入场景没问题不建议把它当成对外 API 的唯一反序列化方案。5Fastjson2可以选前提是团队愿意跟版本、愿意做回归别再把“国内流行”当成安全背书。举个常见场景一个老电商订单服务controller 用 Jackson消息消费和几个工具类却散落着 Fastjson 1.2.7x。一做依赖扫描就一堆洞后面统一迁移的成本往往比一开始定规矩更高。选型省下来的那点“写起来爽”后面都会连本带利还回去。以 2026 年中的风险面看Spring Boot 项目把 Jackson 当默认 JSON 引擎通常比死磕 Fastjson 1.x 更省心。JSON工具类选型没有永恒正确答案但有明确错误答案把停更的 Fastjson 1.x 默认配置继续裸奔在公网入参上。我是程序员天天困持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊你们公司项目里现在用的是 Jackson、Fastjson2、Gson 还是 Hutool踩过哪些坑 JSON工具类选型：Fastjson再爆洞后，项目中该用谁
大家好我是程序员天天困。2026 年 7 月Fastjson 1.x 又爆远程代码执行洞JSON工具类选型这事又被拎到台面上。按阿里官方安全公告致谢发现并负责任披露的是 FearsOff 研究员 Kirill Firsov——影响面覆盖1.2.681.2.83连当年被当成“安全终点”的 1.2.83 也没能幸免。更扎心的是默认解析入口就能走不依赖第三方 gadgetSafeMode 没开就中招。还只看谁解析更快真的会踩雷。洞一公开国内厂商也很快跟上。奇安信 CERT 在2026-07-20发了风险通告腾讯云安全通告页落款是2026-07-23同样点名 CVE-2026-16723并强调这是gadget-free不靠 classpath 里额外危险类的反序列化 RCE下面我会把这次洞、历史坑以及 Jackson / Gson / Hutool 怎么选一次讲清楚。点个收藏我们开始。一、这次 Fastjson 漏洞 CVE-2026-16723 到底怎么回事以 2026 年 7 月底为准还在用 Fastjson 1.2.681.2.83 解析不可信 JSON 的项目应优先当事故处理而不是当“听说有个洞”。时间线按一手源、按日期排一下更清楚1FearsOff / Kirill Firsov 发现并负责任披露阿里官方公告致谢2奇安信 CERT 风险通告公开时间2026-07-203阿里 fastjson2 官方安全公告 标注发布日2026-07-21后于 07-29 更新4腾讯云安全通告 页落款2026-07-23别被二手文章里的“统一 7 月 20 日”带偏——以各家页面自己写的日期为准。阿里官方公告里写得很直白CVECVE-2026-16723影响版本官方fastjson1.2.681.2.83含 1.x 最后一版 1.2.83触发条件默认配置即可AutoType 关、SafeMode 关不需要classpath 上再塞第三方 gadget常见部署前置目标跑在Spring Boot 可执行 fat-jarjava -jar xxx.jar入口JSON.parse、JSON.parseObject(String)、甚至JSON.parseObject(String, Class)都可达——指定 DTO 也不是银弹Object/Map 字段里照样能嵌 payload腾讯云通告也把核心特征写死了无需依赖特定第三方类库即可打到 RCE未开 SafeMode 的 1.x 实例在其通告范围内。有个细节要注意腾讯云通告写的影响版本是1.2.371.2.83比阿里官方 wiki 的1.2.681.2.83更宽做版本自查时我建议以阿里官方安全公告为准同时把云厂商通告当风险信号别互相打架。说人话以前很多团队以为「AutoType 关掉就安全了」。这次官方确认默认关掉也能走通危险路径。更扎心的是1.2.83 曾是 CVE-2022-25845 的修复终点很多人停在这里就再也没动过。官方给出的 P0 动作也很清楚公告更新于 2026-07-291升到fastjson 1.2.842026-07-29 安全修复版2或立刻开SafeMode-Dfastjson.parser.safeModetrue/ParserConfig.getGlobalInstance().setSafeMode(true)3或迁到fastjson2此 CVE 从架构上不受影响另外公告末尾提醒fastjson2 还有独立的 AutoType 加固问题请升到2.0.63 及以上。别把「不受这个 CVE 影响」理解成「永远不用升级」。发现与披露致谢见同一份官方 wikiKirill Firsov / FearsOff。补充一句时效腾讯云通告发出时还写“官方暂未发 1.x 补丁、建议迁 2.x / 开 SafeMode”到2026-07-29阿里已经放出1.2.84。读旧通告时记得对一下后续补丁。二、Fastjson 历史里几次真正伤人的洞Fastjson 的安全史本质上是一条 AutoType 攻防拉锯线不是偶发的“手滑 bug”。AutoType自动类型反序列化时允许 JSON 里用type指定具体 Java 类库再去加载并实例化。类比快递单上你自己填“收件人是谁”快递员按你写的门牌送——写错还是小事写成危险地址就麻烦了。几条经得起一手源核对的节点1CVE-2017-18349Fastjson1.2.25 之前parseObject可被构造请求打到远程代码执行NVD 给出 CVSS 3.x9.8。NVDCVE-2017-183492CVE-2022-25845Fastjson1.2.83 之前默认关闭 AutoType 仍可被绕过反序列化不可信数据可打远程服务器。阿里云漏洞库 AVD-2022-25845披露 2022-06-1131.2.83 → 1.2.842022 年大家把 1.2.83 当终点2026 年 7 月又证明终点会移动。仓库若早已归档、业务又停在 1.x风险窗口会特别长。中间还有一串 AutoType / JNDI 相关的补丁版本例如社区常提的 1.2.48 附近加固细节不必背全记住一句就够只要你还在解析外部不可信 JSONFastjson 1.x 就不该是“装完忘”的依赖。三、Spring Boot 里常见 JSON 工具怎么分工在 Spring Boot 项目里HTTP 出入参的默认选手通常是 Jackson不是 Fastjson。JacksonJava 里最常见的 JSON 序列化/反序列化库Spring MVC / Spring Boot 默认集成。类比厨房里自带的那把主厨刀日常切什么都先找它。GsonGoogle 出品的 JSON 库API 顺手注解体系清晰。类比外出野餐带的折叠刀——好用、好带但不一定是你后厨主力。Hutool JSONUtilHutool 这个 Java 工具全家桶里的 JSON 快捷方法偏“写业务辅助代码时顺手转一下”。类比工具柜里的多功能钳拧螺丝、剪线都行但别拿它当手术刀接公网不可信流量。可能有人会问我记得还有个跟 Hutool 很像的“啥都能干”的库常见是Guava或Jodd。Guava 强在集合、缓存、并发工具本身几乎不当 JSON 引擎团队里往往和 Gson 搭配Jodd 也有 JSON 模块但国内 Spring Boot 项目里出现频率通常低于 Hutool。选型别把“工具全家桶”和“专用 JSON 引擎”混成一件事。Spring Boot 默认链路大致是RequestBody/ResponseBody→HttpMessageConverter→Jackson的ObjectMapper。你在业务里再引一套 Fastjson等于同一项目两套规则——日期格式、空值、多态、异常行为都可能对不上。// 示例业务里自己再套一层时先想清楚是不是真需要第二套引擎ObjectMappermappernewObjectMapper();UserDTOusermapper.readValue(json,UserDTO.class);Stringoutmapper.writeValueAsString(user);四、Fastjson、Jackson、Gson、Hutool 怎么比JSON工具类选型时我优先看“是否解析不可信输入”其次才看 API 爽不爽、跑分漂不漂亮。维度JacksonFastjson / Fastjson2GsonHutool JSONUtilSpring Boot 契合默认集成最省心需额外接入可接非默认非 HTTP 层默认方案安全口碑接公网相对稳仍要控多态配置1.x 历史包袱重2.x 需跟版本通常更克制取决于你怎么用、解析什么API 手感注解强、可定制深静态方法很香学习曲线平工具类超顺手更适合Web API、复杂对象图性能敏感且能跟版本治理简单 DTO、工具脚本内部工具代码、快速转换社区里 JMH / 批量对比文章不少结论经常是小对象谁都差不多大对象、批量场景 Fastjson2 / Jackson 常更亮眼Gson、Hutool 更偏易用。跑分能参考但不能替代安全与生态判断——尤其你刚看完 CVE-2026-16723。你可能会想那 Fastjson 和 Jackson 对比性能党是不是必须上 Fastjson我更建议——先确认你有没有可感知的性能瓶颈。很多接口慢在 DB、远程调用、日志不在 JSON。真要压榨解析再评估 Fastjson2并且把版本升级、SafeMode/白名单策略写进规范别靠口头约定。五、我认为项目里该怎么选以 2026 年 8 月为准我的默认立场新 Spring Boot 项目 HTTP 层用 Jackson遗留 Fastjson 1.x 先止血再谈迁移。落地顺序我会这么排1新项目 / 主链路跟 Spring Boot用Jackson。日期、时区、未知字段、多态用注解和统一ObjectMapperBean 管起来。2已经在用 Fastjson 1.x立刻盘点版本。落在 1.2.681.2.83 且解析外部 JSON按官方建议升1.2.84或开 SafeMode中长期迁fastjson2≥2.0.63或干脆回到 Jackson。3Gson适合 SDK、小工具、对 Google 生态更熟的团队当第二套引擎可以别和 Jackson 在同一条 HTTP 链路上打架。4Hutool JSONUtil继续用在内部转换、测试代码、非不可信输入场景没问题不建议把它当成对外 API 的唯一反序列化方案。5Fastjson2可以选前提是团队愿意跟版本、愿意做回归别再把“国内流行”当成安全背书。举个常见场景一个老电商订单服务controller 用 Jackson消息消费和几个工具类却散落着 Fastjson 1.2.7x。一做依赖扫描就一堆洞后面统一迁移的成本往往比一开始定规矩更高。选型省下来的那点“写起来爽”后面都会连本带利还回去。以 2026 年中的风险面看Spring Boot 项目把 Jackson 当默认 JSON 引擎通常比死磕 Fastjson 1.x 更省心。JSON工具类选型没有永恒正确答案但有明确错误答案把停更的 Fastjson 1.x 默认配置继续裸奔在公网入参上。我是程序员天天困持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊你们公司项目里现在用的是 Jackson、Fastjson2、Gson 还是 Hutool踩过哪些坑