本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
最近 Fastjson 1.x 又被爆出了高达 9.0 分的核弹级漏洞，各大云厂商都发了通告。
然而，一小部分网友们，还只是会骂。
骂完了之后，发现 fastjson 1.x 生于 2012，卒于 2022，停更 4 年后的 2026 年依旧再挨骂。
很多人已经忘记了，开源不是慈善，但很多人把它当成了无限责任的免费售后服务。开源项目不欠任何人一个“永远维护”的承诺。
更何况，我们不应该太擅长做“评论家”，而太不习惯做“建设者”。
一颗迟到的“核弹”
2026 年 7 月 19 日，安全研究员 Kirill Firsov 在 Twitter 上扔下了一颗炸弹。Fastjson 1.x 末代版本（1.2.68–1.2.83）存在一个“无需任何 gadget 链”即可触发的远程代码执行漏洞。
这不是 Fastjson 第一次出事了。从 1.2.24 到 1.2.47，从 autoType 绕过到黑名单绕过，Fastjson 的漏洞史几乎就是一部 Java 反序列化安全编年史。但这一次，情况格外刺眼。
影响版本：1.2.66–1.2.83，涵盖了官方宣称的“最终安全版本” 1.2.83利用条件：默认配置即可触发，关闭 autoType 无效，绑定具体类型也无效危害等级：CVSS 9.8，Spring Boot FatJar + JDK 8 环境下可直接 RCEPOC 公开：披露次日即已有可利用代码在 GitHub 上流传
更现实和讽刺的是，Fastjson 1.x 早在 2024 年就已停止维护，官方最后一次发布 1.x 版本是 2022 年的 1.2.83。也就是说，这个被无数人当作“安全最终版”依赖了数年的版本，其实早已成了一具“尸体”了。
文章配图参见我的公众号：https://mp.weixin.qq.com/s/3w4COY6g7WoOOszjaqdTtg。
大型双标现场
漏洞曝光后，各大技术社区、微信群、知乎、脉脉、云厂商等渠道瞬间炸锅。我随手摘录几条高赞评论给大家看看。
- Fastjson 这破玩意怎么还在用？早该扔进历史的垃圾堆了。
- 阿里巴巴这么大的厂，开源个库就这么不负责任？
- 用了这么多年，说停更就停更，我们的系统怎么办？
- 又是 Fastjson，又是 RCE，国产开源真的不行。
- 这么多条了，开源作者在干啥？
- 写的这么垃圾，转写漏洞的吗？
- 早知道我就不用了
这些吐槽有问题吗？
应该说是没有的。Fastjson 1.x 的安全债确实沉重，历史包袱也确实让人头疼。大家吐槽的心情我也能理解，但不能进行人身攻击呀。
更何况，吐槽解决不了问题呀。
我又翻了翻几个技术群的后续讨论，发现画风出奇一致：
- 有人连夜写排查脚本，扫描公司所有项目的依赖版本。这是标准的行动派。
- 有人紧急开启 SafeMode，先止血再想办法。这应该是一群务实派。
- 但更多的人，在骂完之后，继续用着 1.2.83，继续等着好心人的补丁
要知道，Fastjson 1.x 已经停更两年了。官方早在 2024 年就明确宣布 1.x 仅做安全维护，并推荐所有用户迁移到 Fastjson 2.x。所以，等补丁的话，很可能是一场空，大概率永远不会来了。
最可怕是等靠要的心态
最可怕的不是漏洞，是“等靠要”心态，再加上人身攻击。
这次事件暴露了一个在中文技术社区里长期存在、但极少被正视的问题：“我只管白嫖，出了问题你必须负责修。你不修？那你就是烂，就是不负责任”。
我经常说救病于病情发作之前，Fastjson 1.x 是阿里巴巴开源的一个 JSON 解析库，免费、开源、Apache 协议。你下载它的时候，没有付过一分钱；你把它集成到价值千万的业务系统里的时候，没有签过一份 SLA；你遇到 bug 的时候，没有提交过一个 PR。
然而，当这个免费工具出了问题，你的第一反应是：官方为什么不修？
我提原作者温少说一句，朋友们，这不是商业软件，没有 7×24 的客服热线，也没有“漏洞响应黄金 24 小时”的服务承诺。开源作者把代码放在 GitHub 上，已经履行了“分享”的义务。维护和修复，从来都不是他们的“必须”，而是社区的“共同责任”。
更荒诞的是，这次漏洞的修复方案，官方其实早就给出来了：
| 方案 | 难度 | 效果 |
|---|---|---|
| 迁移到 Fastjson 2.x | 中等（需改依赖 + 部分 API 适配） | 根治，2.x 架构重写，不受此漏洞影响 |
| 开启 SafeMode | 极低（加一行 JVM 参数） | 缓解，彻底禁用 @type 自动加载 |
| 使用 noneautotype 版本 | 低（换 Maven 坐标） | 缓解，编译时移除 AutoType 能力 |
这三个方案，没有一个需要你去 fork 代码、写补丁、发 PR。最难的“迁移到 2.x”，也不过是改改 pom.xml，批量替换一下 import 语句，跑一遍回归测试。
但即便如此，仍有大量开发者选择，先骂，再等，再看看。
开源的搭便车困境
经济学里有个概念叫搭便车问题（Free-rider Problem）。就是说，公共资源的维护需要成本，但每个人都希望别人付出成本，自己坐享其成。
开源软件就是最典型的“公共资源”。
Fastjson 的作者温少（高铁）和他的团队，在过去十几年里维护了这个被数百万项目依赖的库。他们修复了无数个漏洞，处理了无数个 issue，回应了无数个“为什么又出 bug”的质问。然后他们选择将精力投入到重新设计的 Fastjson 2.x 中，这不仅是技术演进，更是一种负责任的态度。与其在腐朽的架构上打补丁，不如给你一个更好的替代品。
但社区的反应是什么？
- 1.x 不维护了？那我们的老项目怎么办？你可以迁移，官方给了完整的迁移指南。
- 迁移成本太高，我们没时间。那你当初选择深度绑定一个第三方库的时候，有没有考虑过技术债的风险？
- 为什么不让 1.x 继续维护？因为维护需要人力，而人力需要资源。你既没有付费，也没有贡献代码，凭什么要求无限期的售后服务？
我这不是在替 Fastjson 洗地。1.x 的安全设计确实有历史局限，autoType 的反复修补更像是一场“打地鼠”游戏。但问题在于当官方已经给出了明确的退出路线（迁移到 2.x）时，继续使用 1.x 并拒绝升级，这个风险是谁的选择？
是你或你的前辈，也或者是团队自己的选择。
成熟的程序员
所以，作为一名技术人、程序员、编程爱好者，应该具备或建立什么样的认知呢？
我觉得应该具备下面几点。
- 接受开源 ≠ 无限责任。不要把开源作者当成你的外包团队。
- 技术债要还，而且越早还越便宜。技术债不会消失，只会利滚利。
- 建立“供应链（第三方或自有类库）安全”意识。
- 参与社区，哪怕只是一点点。不需要成为核心贡献者。发现一个 bug？提个 issue。用了一个好用的功能？在 GitHub 上点个 star，写篇博客分享。有能力修复？fork 之后提个 PR。开源社区的良性循环，靠的不是少数英雄的牺牲，而是大多数人的微小参与。
那些只吐槽不行动的人，那些用着免费软件却要求商业级 SLA 的人，那些出了问题第一时间甩锅而不是排查的人，他们很可能才是开源生态最大的消耗者。
最后
Fastjson 1.x 的漏洞，是一个技术问题，更是一个社区问题。
我们可以批评它的历史设计缺陷，可以讨论国产开源软件的安全文化，可以呼吁企业为开源维护者提供更多支持，因为这些讨论都有价值。
友好的讨论都没问题，有问题的是那些进行人身攻击的，不知道说他们什么好了。
开源的精神不是“你给我修”，而是“我们一起让它变得更好”。行动，永远比吐槽更有力量。
开源社区不是魔法世界，没有免费的午餐，也没有无限责任的守护神。每一个使用开源软件的人，都是这个生态的一部分。你可以选择做一个只索取不付出的“搭便车者”，也可以选择成为一个让社区变得更好的参与者，但千万别只学会了进行人身攻击。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Fastjson 又炸了，爆出了核弹级漏洞