大家好，我是程序员天天困。

2026 年 7 月，Fastjson 1.x 又爆远程代码执行洞，JSON工具类选型这事又被拎到台面上。按阿里官方安全公告致谢，发现并负责任披露的是 FearsOff 研究员 Kirill Firsov——影响面覆盖 **1.2.68～1.2.83**，连当年被当成“安全终点”的 1.2.83 也没能幸免。更扎心的是：默认解析入口就能走，不依赖第三方 gadget，SafeMode 没开就中招。还只看谁解析更快，真的会踩雷。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/f43e1be5fba3742b3d259b53076e9153.png)

洞一公开，国内厂商也很快跟上。奇安信 CERT 在 **2026-07-20** 发了风险通告：

![](https://developer.qcloudimg.com/http-save/yehe-11608098/8ad5e0c620ace0d6febe6aa3ad665a6f.png)

腾讯云安全通告页落款是 **2026-07-23**，同样点名 CVE-2026-16723，并强调这是 **gadget-free**（不靠 classpath 里额外危险类）的反序列化 RCE：

![](https://developer.qcloudimg.com/http-save/yehe-11608098/c478bd6a7311788b44e1e983c244d286.png)

下面我会把这次洞、历史坑，以及 Jackson / Gson / Hutool 怎么选，一次讲清楚。点个收藏，我们开始。

## 一、这次 Fastjson 漏洞 CVE-2026-16723 到底怎么回事

**以 2026 年 7 月底为准，还在用 Fastjson 1.2.68～1.2.83 解析不可信 JSON 的项目，应优先当事故处理，而不是当“听说有个洞”。**

时间线按一手源、按日期排一下更清楚：

1）FearsOff / Kirill Firsov 发现并负责任披露（阿里官方公告致谢）  
2）奇安信 CERT 风险通告公开时间 **2026-07-20**  
3）阿里 [fastjson2 官方安全公告](https://github.com/alibaba/fastjson2/wiki/Security-Advisory:-Remote-Code-Execution-in-fastjson-1.2.68%E2%80%931.2.83) 标注发布日 **2026-07-21**（后于 07-29 更新）  

![](https://developer.qcloudimg.com/http-save/yehe-11608098/6c23241d6059521fdf26c79167bc2249.png)

4）[腾讯云安全通告](https://cloud.tencent.com/announce/detail/2381) 页落款 **2026-07-23**

别被二手文章里的“统一 7 月 20 日”带偏——以各家页面自己写的日期为准。

阿里官方公告里写得很直白：

- **CVE**：CVE-2026-16723
- **影响版本（官方）**：fastjson **1.2.68～1.2.83**（含 1.x 最后一版 1.2.83）
- **触发条件**：默认配置即可（AutoType 关、SafeMode 关），**不需要** classpath 上再塞第三方 gadget
- **常见部署前置**：目标跑在 **Spring Boot 可执行 fat-jar**（`java -jar xxx.jar`）
- **入口**：`JSON.parse`、`JSON.parseObject(String)`、甚至 `JSON.parseObject(String, Class)` 都可达——指定 DTO 也不是银弹，Object/Map 字段里照样能嵌 payload

腾讯云通告也把核心特征写死了：无需依赖特定第三方类库即可打到 RCE，未开 SafeMode 的 1.x 实例在其通告范围内。有个细节要注意：腾讯云通告写的影响版本是 **1.2.37～1.2.83**，比阿里官方 wiki 的 **1.2.68～1.2.83** 更宽；做版本自查时，我建议以阿里官方安全公告为准，同时把云厂商通告当风险信号，别互相打架。

说人话：以前很多团队以为「AutoType 关掉就安全了」。这次官方确认，默认关掉也能走通危险路径。更扎心的是，1.2.83 曾是 CVE-2022-25845 的修复终点，很多人停在这里就再也没动过。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/9083407d69d28ac0f527b42fc749ae87.webp)

官方给出的 P0 动作也很清楚（公告更新于 2026-07-29）：

1）升到 **fastjson 1.2.84**（2026-07-29 安全修复版）  
2）或立刻开 **SafeMode**（`-Dfastjson.parser.safeMode=true` / `ParserConfig.getGlobalInstance().setSafeMode(true)`）  
3）或迁到 **fastjson2**（此 CVE 从架构上不受影响）

另外公告末尾提醒：fastjson2 还有独立的 AutoType 加固问题，请升到 **2.0.63 及以上**。别把「不受这个 CVE 影响」理解成「永远不用升级」。发现与披露致谢见同一份官方 wiki（Kirill Firsov / FearsOff）。

补充一句时效：腾讯云通告发出时还写“官方暂未发 1.x 补丁、建议迁 2.x / 开 SafeMode”；到 **2026-07-29**，阿里已经放出 **1.2.84**。读旧通告时记得对一下后续补丁。

## 二、Fastjson 历史里几次真正伤人的洞

**Fastjson 的安全史，本质上是一条 AutoType 攻防拉锯线，不是偶发的“手滑 bug”。**

**AutoType（自动类型）**：反序列化时允许 JSON 里用 `@type` 指定具体 Java 类，库再去加载并实例化。类比：快递单上你自己填“收件人是谁”，快递员按你写的门牌送——写错还是小事，写成危险地址就麻烦了。

几条经得起一手源核对的节点：

1）**CVE-2017-18349**：Fastjson **1.2.25 之前**，`parseObject` 可被构造请求打到远程代码执行，NVD 给出 CVSS 3.x **9.8**。（NVD：CVE-2017-18349）

2）**CVE-2022-25845**：Fastjson **1.2.83 之前**，默认关闭 AutoType 仍可被绕过，反序列化不可信数据可打远程服务器。（阿里云漏洞库 AVD-2022-25845，披露 2022-06-11）

3）**1.2.83 → 1.2.84**：2022 年大家把 1.2.83 当终点；2026 年 7 月又证明终点会移动。仓库若早已归档、业务又停在 1.x，风险窗口会特别长。

中间还有一串 AutoType / JNDI 相关的补丁版本（例如社区常提的 1.2.48 附近加固），细节不必背全，记住一句就够：**只要你还在解析外部不可信 JSON，Fastjson 1.x 就不该是“装完忘”的依赖。**

![](https://developer.qcloudimg.com/http-save/yehe-11608098/8457bee57bf58399a50a9c9137fd6686.png)

## 三、Spring Boot 里常见 JSON 工具怎么分工

**在 Spring Boot 项目里，HTTP 出入参的默认选手通常是 Jackson，不是 Fastjson。**

**Jackson**：Java 里最常见的 JSON 序列化/反序列化库，Spring MVC / Spring Boot 默认集成。类比：厨房里自带的那把主厨刀，日常切什么都先找它。

**Gson**：Google 出品的 JSON 库，API 顺手，注解体系清晰。类比：外出野餐带的折叠刀——好用、好带，但不一定是你后厨主力。

**Hutool JSONUtil**：Hutool 这个 Java 工具全家桶里的 JSON 快捷方法，偏“写业务辅助代码时顺手转一下”。类比：工具柜里的多功能钳，拧螺丝、剪线都行，但别拿它当手术刀接公网不可信流量。

可能有人会问：我记得还有个跟 Hutool 很像的“啥都能干”的库？常见是 **Guava** 或 **Jodd**。Guava 强在集合、缓存、并发工具，本身几乎不当 JSON 引擎，团队里往往和 Gson 搭配；Jodd 也有 JSON 模块，但国内 Spring Boot 项目里出现频率通常低于 Hutool。选型别把“工具全家桶”和“专用 JSON 引擎”混成一件事。

Spring Boot 默认链路大致是：`@RequestBody` / `@ResponseBody` → `HttpMessageConverter` → **Jackson** 的 `ObjectMapper`。你在业务里再引一套 Fastjson，等于同一项目两套规则——日期格式、空值、多态、异常行为都可能对不上。

```java
// 示例：业务里自己再套一层时，先想清楚是不是真需要第二套引擎
ObjectMapper mapper = new ObjectMapper();
UserDTO user = mapper.readValue(json, UserDTO.class);
String out = mapper.writeValueAsString(user);
```

## 四、Fastjson、Jackson、Gson、Hutool 怎么比

**JSON工具类选型时，我优先看“是否解析不可信输入”，其次才看 API 爽不爽、跑分漂不漂亮。**

| 维度               | Jackson                | Fastjson / Fastjson2         | Gson               | Hutool JSONUtil          |
| ------------------ | ---------------------- | ---------------------------- | ------------------ | ------------------------ |
| Spring Boot 契合   | 默认集成，最省心       | 需额外接入                   | 可接，非默认       | 非 HTTP 层默认方案       |
| 安全口碑（接公网） | 相对稳，仍要控多态配置 | 1.x 历史包袱重；2.x 需跟版本 | 通常更克制         | 取决于你怎么用、解析什么 |
| API 手感           | 注解强、可定制深       | 静态方法很香                 | 学习曲线平         | 工具类超顺手             |
| 更适合             | Web API、复杂对象图    | 性能敏感且能跟版本治理       | 简单 DTO、工具脚本 | 内部工具代码、快速转换   |

社区里 JMH / 批量对比文章不少，结论经常是：小对象谁都差不多；大对象、批量场景 Fastjson2 / Jackson 常更亮眼，Gson、Hutool 更偏易用。跑分能参考，但**不能替代安全与生态判断**——尤其你刚看完 CVE-2026-16723。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/922154c5d52df88f1d130912f55e4504.png)

你可能会想：那 Fastjson 和 Jackson 对比，性能党是不是必须上 Fastjson？我更建议——**先确认你有没有可感知的性能瓶颈**。很多接口慢在 DB、远程调用、日志，不在 JSON。真要压榨解析，再评估 Fastjson2，并且把版本升级、SafeMode/白名单策略写进规范，别靠口头约定。

## 五、我认为项目里该怎么选

**以 2026 年 8 月为准，我的默认立场：新 Spring Boot 项目 HTTP 层用 Jackson；遗留 Fastjson 1.x 先止血再谈迁移。**

落地顺序我会这么排：

1）**新项目 / 主链路**：跟 Spring Boot，用 **Jackson**。日期、时区、未知字段、多态用注解和统一 `ObjectMapper` Bean 管起来。  
2）**已经在用 Fastjson 1.x**：立刻盘点版本。落在 1.2.68～1.2.83 且解析外部 JSON，按官方建议升 **1.2.84** 或开 SafeMode，中长期迁 **fastjson2（≥2.0.63）** 或干脆回到 Jackson。  
3）**Gson**：适合 SDK、小工具、对 Google 生态更熟的团队；当第二套引擎可以，别和 Jackson 在同一条 HTTP 链路上打架。  
4）**Hutool JSONUtil**：继续用在内部转换、测试代码、非不可信输入场景没问题；**不建议**把它当成对外 API 的唯一反序列化方案。  
5）**Fastjson2**：可以选，前提是团队愿意跟版本、愿意做回归；别再把“国内流行”当成安全背书。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/4b214bd83f750a905aa583f9f45bddeb.webp)

举个常见场景：一个老电商订单服务，controller 用 Jackson，消息消费和几个工具类却散落着 Fastjson 1.2.7x。一做依赖扫描就一堆洞，后面统一迁移的成本，往往比一开始定规矩更高。选型省下来的那点“写起来爽”，后面都会连本带利还回去。

---

以 2026 年中的风险面看，Spring Boot 项目把 Jackson 当默认 JSON 引擎，通常比死磕 Fastjson 1.x 更省心。

JSON工具类选型没有永恒正确答案，但有明确错误答案：把停更的 Fastjson 1.x 默认配置，继续裸奔在公网入参上。

我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你们公司项目里现在用的是 Jackson、Fastjson2、Gson 还是 Hutool，踩过哪些坑？

2026 年 7 月，Fastjson 1.x 又爆远程代码执行洞，JSON工具类选型这事又被拎到台面上。按阿里官方安全公告致谢，发现并负责任披露的是 FearsOff 研究员 Kirill Firsov——影响面覆盖 1.2.68～1.2.83，连当年被当成“安全终点”的 1.2.83 也没能幸免。更扎心的是：默认解析入口就能走，不依赖第三方 gadget，SafeMode 没开就中招。还只看谁解析更快，真的会踩雷。

JSON工具类选型：Fastjson再爆洞后，项目中该用谁

JSON工具类选型别再只看速度。梳理 Fastjson CVE-2026-16723 与历史洞，对比 Jackson、Gson、Hutool 给落地建议

编程语言

安全

后端

Fastjson1.x爆出CVE-2026-16723远程代码执行漏洞，影响1.2.68-1.2.83版本，默认配置即可触发。建议升级至1.2.84或开启SafeMode，或迁移至Fastjson2。对比Jackson、Gson等JSON工具，SpringBoot项目推荐默认使用Jackson，安全性和兼容性更优。解析不可信JSON时应优先考虑安全因素而非性能。

代码解释

服务器

云安全

JSON

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Fastjson1.x爆出CVE-2026-16723远程代码执行漏洞，影响1.2.68-1.2.83版本，默认配置即可触发。建议升级至1.2.84或开启SafeMode，或迁移至Fastjson2。对比Jackson、Gson等JSON工具，SpringBoot项目推荐默认使用Jackson，安全性和兼容性更优。解析...

JSON工具类选型：Fastjson再爆洞后，项目中该用谁-腾讯云开发者社区-腾讯云

JSON工具类选型：Fastjson再爆洞后，项目中该用谁

JSON工具类选型：Fastjson再爆洞后，项目中该用谁

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐