2022年6月，fastjson 1.2.80版本被曝出存在反序列化漏洞。攻击者构造一个看似普通的JSON字符串，就能在目标服务器上执行任意命令。这不是fastjson第一次出事，从2017年的1.2.24到后来的1.2.47、1.2.68，几乎每隔一段时间就有新的绕过方式冒出来。阿里云安全团队当年发过一份报告，说fastjson的漏洞利用链已经形成了"生态"，这话一点不夸张。

问题出在fastjson的autoType机制上。简单说，fastjson在反序列化时，会根据JSON里的@type字段去加载对应的Java类。设计初衷是好的——方便开发者直接把JSON转成特定对象。但攻击者可以指定任意类，比如com.sun.rowset.JdbcRowSetImpl，这个类在特定条件下会触发JNDI注入，进而加载远程恶意类。整个过程不需要目标系统有任何额外配置，只要用了fastjson且开启了autoType，基本就是敞开的门。

我见过一个真实案例。某电商平台的后端服务用了fastjson做API参数解析，版本是1.2.60。攻击者通过一个评论接口提交了恶意JSON，服务器直接反弹了一个shell到境外IP。从提交请求到拿到服务器权限，前后不到三秒。事后排查发现，这个接口只需要普通用户权限就能访问，连登录态都没严格校验。fastjson的漏洞利用门槛低到这种程度，稍微懂点Java反序列化的人都能上手。

为什么fastjson的RCE漏洞屡禁不止？根本原因在于autoType的设计哲学。它本质上是一个"白名单"机制，但白名单的维护成本极高。Java生态里的类太多了，攻击者总能找到新的利用链。fastjson官方每次修复都是加黑名单，攻击者换个类名继续绕过。这种猫鼠游戏持续了好几年，直到1.2.83版本才默认关闭了autoType。但很多老系统还在用旧版本，升级成本高，风险就这么一直挂着。

防御其实不复杂。最直接的办法是升级到最新版，并且显式关闭autoType。如果业务上确实需要多态反序列化，可以用ParserConfig.getGlobalInstance().addAccept()做严格白名单，只允许特定的类。另外，JNDI注入的防护也重要——把com.sun.jndi.ldap.object.trustURLCodebase设为false，能挡住大部分远程类加载。但说实话，很多团队直到被入侵了才想起来做这些。

我个人的判断是，fastjson的问题不只是技术漏洞，更是设计取舍的代价。为了性能和多态支持，牺牲了安全性。在金融、政务这些对安全要求高的场景，我一般建议直接用Jackson或Gson替代。fastjson的快是快，但快不能当饭吃。一个RCE漏洞的代价，可能是整个数据库被拖走，或者服务器变成矿机。这笔账怎么算都不划算。

现在回头看，fastjson的RCE史几乎就是Java反序列化漏洞的缩影。从Commons Collections到Shiro，再到fastjson，利用链越来越成熟，工具越来越自动化。攻击者不需要理解底层原理，拿现成的payload打就行。防守方呢？还在为要不要升级一个jar包开会讨论。这种不对称，才是安全最头疼的地方。