事件概述
最近一条值得站长、运维和 Java 开发者一起盯住的安全新闻，是 FastJson 1.x 被披露存在可在野利用的远程代码执行漏洞。官方安全公告和 NVD 都确认，受影响的是 FastJson 1.2.68 到 1.2.83，且问题在默认配置下就可能被触发；更麻烦的是，它主要落在很多人习惯直接上线的 Spring Boot 可执行 fat-jar 场景里。
这类漏洞的危险不在于“理论上能打”，而在于它碰上了现实里最常见的 Java 部署方式。很多中小企业、内部系统、接口服务和管理后台，都会把 JSON 解析放在业务入口最前面。一旦项目里还在用 FastJson 1.x，就不能只把它当成一个依赖版本号，而要把它当成一个会不会被远程打到应用核心的风险点。
为什么这次要认真看
FastJson 是 Java 生态里很常见的 JSON 库，尤其在一些历史项目、老平台和国产中间件里出现频率很高。按照官方公告，这次漏洞不要求你主动开启 AutoType，也不需要攻击者提前找到复杂 gadget 链，说明它不是那种“配置错了才会中招”的老问题，而是更接近默认路径上的逻辑缺陷。
对于运维来说，这意味着排查不能只盯公网入口。只要你的服务能接收外部 JSON 输入，就应该检查依赖树里是否还残留 FastJson 1.2.68 到 1.2.83，尤其是 Spring Boot 打包成可执行 fat-jar 的应用。对站长和业务负责人来说，这种漏洞一旦被打穿，后果可能不只是接口报错，而是应用进程被拿下，进一步带来数据泄露、WebShell、横向移动甚至整台服务器失守。
攻击前提与利用面
公开资料里提到，这个漏洞主要和 Spring Boot 可执行 fat-jar 的部署方式绑定。换句话说，它不是所有 FastJson 项目都会被一口气打中，但只要你的应用满足这个前提，就需要立刻把它当成高风险问题处理。官方说明还强调，JSON.parse、JSON.parseObject(String)、JSON.parseObject(String, Class) 等常见入口都可能触达风险路径。
另一个容易误判的点是：别以为“我已经指定了 DTO 类”就安全了。官方和安全分析都指出，攻击者可以把 payload 藏进 Object 或 Map 类型字段里，照样绕到危险路径。对工程团队来说，这意味着代码层面不能只改一两个参数名就算结束，而要从依赖替换、运行参数和打包方式一起看。
普通用户和企业为什么要关注
如果你是普通用户，最直接的感受可能不是浏览器报错，而是后台系统异常、登录失败、接口被重启，或者云主机资源突然飙高。对于企业来说，危险更现实：很多内网业务、OA、ERP、工单、报表系统，背后都是 Java 服务。一旦其中某个入口被远程执行代码，攻击者就可能沿着同机服务、配置文件、凭据和内部 API 一层层往里摸。
对中小企业运维来说，这类问题尤其容易被忽略，因为项目往往不是单一代码仓库，而是多个历史系统拼在一起。某个老应用在几年之前引入了 FastJson，后来没人再动它，但它还活着。这样的“沉睡依赖”正是攻击者喜欢的目标：外面看起来平平无奇，里面却可能保留着旧版本的危险解析链。
排查思路
先做最小成本的确认：梳理 Java 项目的依赖树，重点找 fastjson 1.x，确认是否落在 1.2.68 到 1.2.83 之间。再看打包方式，是否是 Spring Boot 可执行 fat-jar，以及应用是否直接处理外部 JSON。若团队同时维护多个服务，建议把排查范围放到构建产物、镜像和线上包三层，不要只看源码仓库。
然后看运行参数和配置。官方给出的缓解建议里，SafeMode 是首选临时措施之一；如果确实还要留在 1.x，至少要确认是否已经启用 SafeMode，或者是否使用了 noneautotype 构建。与此同时，建议检查 WAF、反向代理和应用日志里有没有异常 JSON 请求、@type 相关特征、jar:http / jar:file 这类可疑路径痕迹。
修复和缓解建议
最稳妥的办法当然是迁移到 FastJson 2.x。官方公告明确说，fastjson2 不受这次问题影响，根因在架构上已经被消掉。如果短期内不能升级，至少要按官方建议立刻启用 SafeMode，或切换到 noneautotype 构建，并尽快安排兼容性测试和灰度验证。
如果服务已经暴露在公网，别只盯代码修补。建议同步收紧访问面，把管理接口、测试接口和非必要 JSON 入口先隔离；查看是否有异常进程、非预期外联、意外文件变更、未知压缩包或 WebShell 痕迹；如果怀疑已经被打穿，先保留日志和时间戳，再谈重建或回滚。对于已经确认存在风险的生产系统，升级、重启和重载都要先评估业务影响，别为了“快”把服务弄停得更久。
后续观察
这类 Java 生态漏洞有个老问题：真正危险的不是公告当天，而是之后几周里，那些还没清完的历史系统。FastJson 又偏偏是那种“老项目里经常还在”的依赖，所以这次更像一次全链路清点机会。短期看，团队要尽快确认是否受影响；中期看，要把 JSON 解析依赖和打包方式纳入常规安全基线；长期看，能迁到更现代、默认更安全的库，就别再给老解析链留后门。
如果你的系统已经在用 FastJson 1.x，这次最好不要拖。先确认版本，再确认部署形态，再确认缓解措施是否真的生效。安全这件事从来不怕多看一眼，怕的是“看起来没问题”然后被远程打进来。
