摘要：安全研究团队FearsOff披露，Fastjson 1.2.68至1.2.83存在新的远程代码执行风险，且不依赖额外第三方Gadget。完整技术细节尚未公开，企业当前最需要做的是先排清Fastjson 1.x资产、评估SafeMode，并制定迁移Fastjson 2的时间表。
2026年7月，安全研究团队FearsOff披露，Fastjson 1.2.68至1.2.83版本存在一项远程代码执行风险。
研究团队称，攻击不要求目标系统额外安装特定的第三方“Gadget”类库，一个恶意JSON请求就可能触发代码执行。过去通过删除Commons Collections、Groovy等危险依赖降低风险的做法，无法覆盖这次披露的利用路径。
受影响范围包括Fastjson 1.x的最终版本1.2.83。
这使问题变得更加棘手。2022年，1.2.83本身就是一次安全更新，用于修复特定场景下绕过AutoType关闭限制的漏洞。Fastjson官方当时建议用户升级到1.2.83，或者开启SafeMode。
截至2026年7月21日，这次新漏洞尚未获得公开CVE编号，研究团队也没有发布完整技术分析。FearsOff表示，详细报告将在相关机构完成处置后公布。当前能够确认的信息主要包括影响版本、攻击条件和应对建议。
企业此时最需要处理的工作，不是研究攻击代码，而是查清Fastjson 1.x究竟存在于哪些系统中。
Fastjson为什么会进入这么多Java系统
Fastjson是一款Java JSON处理库。
Java应用接收网页请求、调用第三方接口或者读取配置文件时，经常需要把JSON文本转换成Java对象。Fastjson提供了较为简洁的API，并长期以解析速度快、使用方便著称。
在国内Java生态中，它被大量用于：
电商和支付系统；
政务服务平台；
金融业务系统；
微服务网关；
移动应用后台；
数据交换接口；
制造企业管理软件；
第三方软件产品和中间件。
很多系统并不是由开发人员主动选择Fastjson。
一个应用可能通过某个开发框架、SDK、基础组件或旧版中间件间接引入Fastjson。开发团队查看业务代码时未必能够看到它，运行环境中却已经包含相应JAR包。
Maven公共仓库的统计页面显示，Fastjson相关组件仍被数千个项目引用。这个数字只能反映公开登记的直接使用情况，无法覆盖企业内部软件、封闭项目和已经停止开发的旧系统。
因此，漏洞通报发布后，仅在代码仓库中搜索一遍“fastjson”通常不够。
这次“无需Gadget”意味着什么
Java反序列化攻击经常提到Gadget Chain。
Gadget可以理解为目标系统中已经存在的一段可被利用的代码。攻击者把多个类和方法连接起来，在反序列化过程中触发文件读取、网络访问或命令执行。
过去处理Fastjson风险时，安全人员常会检查系统里是否存在某些已知危险类库。
假如攻击依赖Commons Collections、Groovy、某种数据库驱动或特定Spring组件，企业可以通过升级、删除依赖或调整类路径，破坏攻击链。
FearsOff此次使用“gadget-free”描述新漏洞，并进一步解释，攻击不依赖目标类路径中的额外第三方Gadget。研究团队确认1.2.68至1.2.83均受影响，并称传统的类路径清理措施无法阻断这一问题。
这里仍需保持谨慎。
完整技术报告尚未发布，外界目前无法独立审查漏洞成因、适用条件和全部利用限制。企业不应根据网上流传的测试代码直接判断自身系统一定能够被攻击，也不应因为测试未成功就判定系统安全。
版本、配置、调用方式和数据入口需要一起检查。
关闭AutoType不等于开启SafeMode
Fastjson的安全问题长期与AutoType有关。
JSON数据通常只包含字段和值。AutoType功能允许JSON内容指定要实例化的Java类型，给多态对象转换带来便利，也让不可信输入有机会影响服务器加载和调用哪些类。
Fastjson在后续版本中逐步限制AutoType，增加黑名单、白名单和类型检查机制。
但“AutoType默认关闭”和“SafeMode已经开启”并不是同一种状态。
Fastjson官方文档显示，SafeMode从1.2.68开始提供。开启后，AutoType会被完全禁用，原有白名单和黑名单配置也不会继续放行自动类型转换。
官方提供了三种开启方式。
可以在程序代码中配置：
1 | ParserConfig.getGlobalInstance().setSafeMode(true); |
也可以增加JVM启动参数：
1 | -Dfastjson.parser.safeMode=true |
还可以通过fastjson.properties配置文件启用。
研究团队针对本次漏洞给出的临时建议也是：仍在使用Fastjson 1.x的系统应立即开启SafeMode，并尽快迁移到Fastjson 2。
开启前需要评估业务兼容性。
部分系统可能依赖AutoType还原接口对象、消息对象或复杂继承结构。直接启用SafeMode后，这些功能可能出现解析失败，不能在未经测试的情况下直接修改所有生产节点。
安全团队和开发团队需要同时参与。
1.2.83曾经是安全版本
这次事件容易造成理解混乱，因为1.2.83在过去四年里一直被视为Fastjson 1.x的安全升级目标。
2022年5月，Fastjson发布1.2.83，修复了特定场景下绕过AutoType关闭限制的问题。官方安全公告给出的处置方案包括升级至1.2.83和开启SafeMode。
美国国家漏洞数据库后来将此前的问题登记为CVE-2022-25845，受影响范围为1.2.83之前的版本。
许多企业因此形成了一条固定检查规则：
低于1.2.83，需要升级；
等于1.2.83，可以继续使用。
2026年的新披露打破了这条判断。
如果研究团队公布的影响范围最终得到完整技术报告和更多厂商验证，Fastjson 1.x将不存在一个可以通过小版本更新获得修复的公开版本。
企业不能再把“已经升级到1.2.83”当作处置完成。
停止维护的软件不会自动退出生产环境
Fastjson 1.x代码仓库已经进入只读状态，项目主页也明确推荐用户迁移到Fastjson 2。
软件停止维护后，企业应用不会同步消失。
一套Java系统可能运行十年。期间经历多次人员更换、外包交付、服务器迁移和业务改造，底层依赖却一直保留。
常见情况包括：
系统已经没有原始开发团队；
源代码不完整，只保留可运行的JAR包；
供应商已经停止维护产品；
升级依赖会影响大量接口；
系统只能运行在旧版JDK上；
生产环境缺少完整测试条件；
业务部门不愿承担停机风险。
这类系统遇到高危漏洞时，很难在几天内完成框架迁移。
安全部门只能先通过配置、网络隔离、访问控制和流量监测降低风险，再安排后续改造。
这也是Fastjson事件更值得关注的地方。漏洞位于一个基础组件中，却可能分散在大量多年未改动的业务系统里。
企业排查不能只看源码
Fastjson资产排查至少要覆盖五个位置。
第一，代码依赖文件。
检查Maven的pom.xml、Gradle配置和依赖锁定文件。除了直接声明的com.alibaba:fastjson，还要查看完整依赖树，识别由其他组件间接带入的版本。
第二，构建产物。
检查已经打包的JAR、WAR和EAR文件。部分项目在构建时会把Fastjson代码合并进一个大型JAR包，源码仓库中的依赖记录与生产文件可能不一致。Spring Boot应用常把依赖放在BOOT-INF/lib目录内，也需要单独展开检查。
第三，容器镜像。
企业已经修改了代码仓库，不代表运行中的容器镜像同步更新。镜像仓库里可能还保存着多年前构建的版本，生产环境也可能继续运行旧镜像。
第四，商业软件和第三方产品。
很多办公系统、报表平台、数据交换工具和行业软件使用Java开发。企业拿不到源码，只能通过软件物料清单、供应商公告、文件扫描和运行时监测确认组件版本。
第五，备份和灾备环境。
主系统完成修复后，备用机房、测试环境和历史恢复包仍可能保留旧组件。发生故障切换或者恢复历史版本时，已经消除的漏洞可能重新进入运行环境。
先判断哪些入口能够接收外部JSON
发现Fastjson 1.x后，还需要判断实际暴露程度。
使用同一个版本的两套系统，风险可能完全不同。
一套系统只在内部离线任务中解析固定配置文件，另一套系统直接把互联网用户提交的JSON交给Fastjson处理，后者需要更高的处置优先级。
企业可以从几个问题入手：
系统是否对互联网开放；
是否存在接收JSON请求的API；
请求内容能否直接进入Fastjson解析函数；
是否通过消息队列接收外部数据；
是否允许用户上传JSON或配置文件；
内部接口是否缺少身份认证；
解析进程具有什么系统权限；
应用服务器能否主动访问互联网；
服务器是否保存数据库和云平台凭证。
远程代码执行只是攻击的起点。
攻击者取得应用进程权限后能够做什么，取决于服务器权限、网络位置和凭证管理。以低权限账号运行服务、限制出站网络、隔离数据库和缩小云平台权限，都能降低后续影响。
开启SafeMode是临时措施，迁移仍需测试
Fastjson 2被官方定义为Fastjson的下一代版本，针对JDK 8、11、17和21进行了优化，并采用默认关闭AutoType的设计。
企业可以选择两种迁移方式。
一种是直接使用Fastjson 2的新包名：
1 | com.alibaba.fastjson2 |
这种方式需要修改代码中的导入路径和部分API调用。
另一种是使用Fastjson 2提供的1.x兼容包，继续采用原有坐标：
1 | com.alibaba:fastjson |
兼容包可以降低改造量，但官方明确说明无法保证百分之百兼容，迁移后仍需完成业务测试。
重点测试内容包括：
日期和时间格式；
大数字精度；
空值处理；
枚举转换；
字段大小写；
泛型对象；
继承关系；
自定义序列化器；
JSONPath表达式；
Spring消息转换器；
缓存和消息队列中的历史数据。
JSON库处于数据交换层，一个细微行为变化就可能影响多个系统之间的接口。
因此，迁移不能只验证项目能否编译，还要比对同一批输入在新旧版本中的解析结果。
无法立即迁移的系统如何处理
部分老系统短期内确实无法升级。
企业可以先采取组合措施。
首先，确认并开启SafeMode，同时验证业务功能。
其次，限制外部JSON直接进入通用解析接口。接口应绑定明确的Java类型，避免把不可信输入解析成任意对象。
第三，在网关和Web应用防火墙上增加异常JSON监测。规则只能作为补充，不能替代组件修复，因为攻击载荷可能存在多种编码和结构变化。
第四，降低Java进程权限。应用账号不应拥有系统管理员权限，也不应能够修改启动脚本和核心程序目录。
第五，限制服务器出站连接。多数业务系统不需要任意访问互联网，可以通过域名、IP和端口白名单控制。
第六，轮换应用能够读取的敏感凭证，并缩小数据库、对象存储和云平台账号权限。
第七，保留完整请求日志、应用日志和进程行为记录，为后续调查提供依据。
这些措施可以缩小攻击面，却不能改变组件已经停止维护的事实。
技术债最终会变成安全债
基础组件升级经常被推迟，因为它不会立即增加业务功能。
版本还能运行，接口也没有报错，团队很容易把迁移安排到下一期。
时间久了，依赖关系会变得越来越复杂。
旧组件绑定旧框架，旧框架绑定旧JDK，旧JDK又绑定某个操作系统。等到高危漏洞出现，企业面对的已经不是替换一个JAR包，而是一整套系统改造。
Fastjson 1.x事件给企业提供了一次资产检查机会。
需要建立的不只是一张Fastjson清单，还包括：
每个系统使用哪些开源组件；
组件通过哪条依赖链进入；
当前是否仍在维护；
供应商是谁；
系统暴露在哪些网络区域；
出现漏洞后由谁负责升级；
无法升级时采用哪些隔离措施。
软件物料清单只有持续更新，才能在漏洞发布后快速定位影响范围。
否则，企业最先遇到的问题往往不是“怎么修”，而是“我们到底有没有使用”。
从1.2.83开始排查，也要准备退出1.x
截至2026年7月21日，Fastjson新漏洞仍处于协调披露阶段。
完整成因、漏洞编号和最终影响条件仍需等待研究团队、项目方及更多安全机构进一步确认。企业不必传播未经验证的攻击代码，也不应等待全部细节公开后才开始行动。
现阶段可以完成三件事：
查清所有Fastjson 1.x资产；
评估并开启SafeMode；
制定迁移Fastjson 2的时间表。
1.2.83曾经解决过上一轮安全问题，却无法保证未来继续获得补丁。
停止维护的软件留在生产环境中的时间越长，下一次漏洞出现时可用的选择就越少。
Fastjson这次风险提醒企业，基础组件管理不能只记录“当前版本是否有漏洞”。还要记录它是否仍有人维护，以及企业准备在什么时候离开它。
参考资料：
FearsOff：《gadget-free Remote Code Execution vulnerability in Fastjson 1.2.83》，2026年7月。
Alibaba Fastjson：fastjson_safemode文档、1.2.83安全更新说明、Fastjson 2迁移文档。
NVD：CVE-2022-25845。
MvnRepository：com.alibaba:fastjson组件统计页面。