作为国内乃至全球 Java 开发者最常用的 JSON 数据解析组件之一，阿里巴巴开源的 Fastjson 曾因频繁爆发的反序列化漏洞而成为安全运维人员的噩梦。2026年7月中旬，Java 安全领域再度爆发地震。知名安全研究员基里尔·菲尔索夫（Kirill Firsov）公开披露了针对 Fastjson 1.x 分支的全新高危零日远程代码执行（RCE）漏洞，彻底打破了安全社区以往认为“不开启 AutoType 且无 Gadget 即安全”的侥幸心理。
根据基里尔·菲尔索夫在社交平台X上披露的Fastjson高危RCE漏洞细节，该漏洞的影响范围锁定了 Fastjson 从 1.2.68 到 1.2.83 之间的所有版本。这意味着，大量仍在生产环境中运行、依赖旧版本 Fastjson 的老旧系统，已经在没有防护补丁的情况下直接暴露在了黑客的扫描射程之内。
无需 AutoType 与依赖类：直接撕裂底层 JDK 防线
传统上，Fastjson 的反序列化攻击链条需要满足两个关键前提：一是目标应用必须显式开启 autoTypeSupport 以允许解析特定类，二是目标服务器的依赖库（classpath）中必须存在能够被恶意调用的“工具类”（即 Gadget，如 Common Collections 等）。
然而，本次曝光的漏洞机制却绕过了上述所有限制。黑客在发起攻击时，无需开启 autoType 选项，也完全不依赖目标服务器上是否存在特定的 classpath gadget。这种“无 Gadget”的特性意味着几乎任何以默认配置运行受影响版本 Fastjson 的 Java 服务都是易受攻击的。更为严峻的是，该漏洞在技术实现上展现出了惊人的向后兼容性。经过安全团队的初步测试，该利用链不仅在服役时间最长的 JDK 8 运行环境中有效，甚至在目前企业主推的 JDK 17、JDK 21，以及刚刚发布不久的 JDK 25 下均能实现稳定利用，可以说是通杀多代 Java 运行环境。
批量验证工具流出：默认回传执行结果
在该高危漏洞细节公布后不到 24 小时，黑客社区与开源安全平台上便迅速流出了相关的武器化利用工具。
根据目前在GitHub上公开的Fastjson 1.2.83无Gadget远程代码执行PoC验证项目显示，该验证脚本不仅集成了对 JDK 8、17、21 和 25 版本的自动化适配尝试，还配备了强大的批量扫描功能。安全研究员通过分析该 PoC 的代码细节发现，其默认的攻击载荷（Payload）在侵入目标服务器后，会首先执行系统级命令 id，并通过 HTTP POST 请求将命令执行的结果回传至攻击者监听端的 /out 路径中。这种即时反馈的机制，极大便利了攻击者对大范围网络资产进行自动化的“漏洞普查”，使得企业应急响应的压力成倍增加。
1.x 分支早已寿终正寝：官方拒发补丁，升级成唯一生路
面对汹涌的攻击波潮，使用 Fastjson 1.x 的企业将无法指望来自官方的更新支持。早在 2024 年 10 月，Fastjson 官方维护团队就已经正式宣布停止对 1.x 版本的维护工作。因此，除非出现极度特殊的国家级安全干预，否则官方将不会为该分支推送任何新的安全补丁。
针对这一困境，安全专家指明了两条防御自救路线。首选且最根本的解决方案是，企业必须立刻组织开发团队排查所有的 maven 依赖，彻底将 JSON 解析组件重构并迁移至目前仍在接受维护的 Fastjson 2 分支或其他主流 JSON 库（如 Jackson 或 Gson）。对于因业务过于繁重、短期内无法重写代码的系统，运维人员应立即在 Java 虚拟机的启动参数或项目的全局配置文件中显式启用 SafeMode（安全模式）。SafeMode 会在底层彻底禁用 autoType 的任何变相调用，虽然可能会导致极少数依赖该特性的业务出现异常，但在目前 PoC 已经满天飞的情况下，这也是保全企业核心数据库与服务器主控权最直接的物理护盾。
本报道由 圈小蛙（qxwa.com） 科技资讯站特约撰稿。🐸️